Новости из Блогов Анализ уязвимостей Ajax

Анализ уязвимостей Ajax
Как защитить Web-приложения, создаваемые с помощью Ajax



Введение

Часто используемые сокращения:

• Ajax: Asynchronous JavaScript + XML
• CSS: Cascading style sheet - каскадная таблица стилей
• DOM: Document Object Model
• HTML: HyperText Markup Language
• JSON: JavaScript Object Notation
• SQL: Structured Query Language - структурированный язык запросов
• UI: User Interface - интерфейс пользователя
• XML: Extensible Markup Language – расширяемый язык разметки
• XSS: Cross-site scripting - межсайтовый скриптинг

Рост популярности Ajax среди Web-разработчиков вызван тем, что этот набор технологий:

• позволяет создавать надежные Web-приложения, использующие управляемые данными Web-сайты;
• повышает быстродействие и удобство использования Web-сайтов.

Однако "технология", на которую опираются многие Web-разработчики, чтобы сделать свои Web-приложения похожими на традиционные настольные приложения, на самом деле вообще не является технологией. Ajax представляет собой набор технологий, каждая из которых играет важную роль в готовом программном продукте. Технологии, входящие в Ajax, перечислены в таблице 1.

Таблица 1. Технологии, используемые в Ajax


То, что привлекает Web-разработчиков к Ajax, несет в себе серьезные угрозы для безопасности. Большинство экспертов по безопасности согласны с тем, что Web-приложения служат большой мишенью для киберпреступников, но на долю Web-безопасности в целом приходится лишь небольшая часть бюджета , выделяемого организациями на безопасность. Ajax используется для разработки многих приложений, которые можно увидеть в Интернете, и его популярность делает его мишенью для злоумышленников, которые ищут уязвимости в коде JavaScript.

Ajax существует для того, чтобы создавать Web-сайты, управляемые данными. Однако Ajax привлекает злоумышленников не только как инструмент разработки Web-приложений. Данные – финансовые, личные или конфиденциальные – золотое руно онлайн-потребления, и здесь Ajax тоже оказывается в центре внимания киберпреступников.

В этой статье рассматриваются некоторые общие уязвимости и угрозы для безопасности, нацеленные на Ajax, включая атаки на браузер, SQL-инъекции, XSS и Ajax-мосты, а также предлагаются некоторые профилактические меры, которые можно предпринять для защиты от атак.


Типы атак


Безопасность AJAX: что стоит за цифрами:
С помощью Ajax создано несметное число Web-приложений. Это один из самых популярных инструментов разработки, однако можно предположить, что среди 73% Web-приложений, которые, как известно, были взломаны за последние 24 месяца:

-2155 имели известные уязвимости;
-в 83% была по крайней мере одна серьезная уязвимость.

Ajax играет в этом уравнение довольно значительную роль.

Уязвимости JavaScript создают нежелательное давление на многие компании. Атакуя уязвимости типа межсайтового скриптинга (XSS), злоумышленники обманывают код JavaScript и крадут куки-файлы сеансов посетителей сайтов. Эти куки-файлы содержат данные, позволяющие злоумышленникам получить доступ к любой из услуг, с которой связаны учетные записи жертвы.

Знаменитый червь Samy фактически начинался как шутка, направленная на то, чтобы собрать побольше друзей на сайте социальной сети. Создатель червя через свой профиль загружал в компьютеры жертв вредоносный код, который:

• добавлял каждого, кто посещает их профили, в его список друзей;
• писал в нижней части экрана профилей жертв "Samy - мой герой";
• копировал себя всем, чьи имена находились в списке жертвы.

Менее чем через 24 часа после первого сообщения о заражении на счету Samy был 1 млн друзей и взломанных сайтов.

Использование Ajax не подвергает Web-сайт сколько-нибудь большему риску, чем любая другая Web-технология – особенно, если знать, какие именно угрозы существуют. В остальной части этой статьи описаны некоторые из уязвимостей, которые можно предвидеть, и план действий, рекомендуемых при разработке.


Атаки на основе браузера

JavaScript, лежащий в основе Ajax, не застрахован от вредоносного кода. Для того чтобы атака на базе браузера сработала, вредоносный код должен иметь возможность использовать Web-технологию (в данном случае, JavaScript) и сделать так, чтобы сам браузер запустил программу злоумышленника.

В простых случаях атак на основе браузера у жертвы меняется домашняя страница, или при попытке ввода URL в адресную строку они перенаправляются на другой сайт. Это неприятно, но существуют сценарии и похуже.

Многие атаки на основе браузера нацелены на то, чтобы помешать зараженному компьютеру обнаружить или отразить их. Часто в результате атаки на браузер жертва не может попасть на сайт для удаления вредоносных программ или загрузить файл с обновлением сигнатур через Web. В число других угроз входят подлог браузера и перехват нажимаемых клавиш.

Профилактические меры

Чтобы защититься от атак на основе браузера, достаточно отключить поддержку Java™, JavaScript и элементов Microsoft® ActiveX®. Однако в этом случае перестанут работать многие Web-приложения. Лучше просто поддерживать актуальный уровень операционной системы, браузера и антивирусного ПО. Кроме того, следует использовать надежный межсетевой экран и проявлять осторожность при загрузке файлов и посещении Web-сайтов.


SQL-инъекции

Каким образом SQL-инъекции могут угрожать Ajax? Ведь в Ajax нет буквы "S". SQL-инъекции представляет угрозу просто потому, что Ajax работает на стороне клиента. На стороне сервера Web-приложению требуется база данных, а это означает SQL.

SQL-инъекция происходит, когда злоумышленник вводит вредоносный код в слабо проработанную область Web-сайта, например, в форму. Если атакуемый сайт уязвим, опасности может подвергаться все содержимое базы данных. Этот метод атаки использовался, когда из одной системе онлайн-платежей был взломан пароль базы данных и украдены данные кредитных карт. А совсем недавно с помощью этого метода были похищены адреса электронной почты фанатов с Web-сайта популярного артиста. Это не пропажа денег, но украденные адреса использовали спамеры, распространявшие вредоносный код под видом предложений агента этого артиста.

Меры защиты от SQL-инъекций в приложениях, разработанные с использованием Ajax, те же, что и для любых других Web-технологий. Однако для защиты от атак этого типа недостаточно одних профилактических мер на основе JavaScript. JavaScript выполняется на стороне клиента, а не сервера, где происходит SQL-инъекция.

Профилактические меры

Для защиты базы данных от атак с использованием Ajax необходимо проверять вводимые пользователем данные на стороне сервера. Параметризованные, или подготовленные, операторы предотвращают SQL-инъекции, потому что значения параметров не помещаются непосредственно в базу данных или SQL-оператор. Вместо этого используется заполнитель (или переменная связывания), а значения заполнителя передается посредством отдельного вызова API.


Межсайтовый скриптинг

XSS ― еще один пример инъекций злоумышленников, когда вредоносный код вводится в приложение. В число Web-приложений, уязвимых для атак, входят сценарии XSS на стороне браузера вроде тех, что обычно используются для Ajax. Как правило, уязвимости этого типа применяются для передачи вредоносных сценариев ничего не подозревающим посетителям Web-сайта. Эти сценарии используются для кражи персональных данных и куки-файлов, слежения за посещаемыми Web-сайтами, доступа к конфиденциальной информации и даже для атак, вызывающих отказ в обслуживании.

В знаменитой XSS-атаке 2010 года был замешан Web-сайт обмена сообщениями социальной сети. Инициированная пользователем по имени @Matsta, эта атака вызывала появление всплывающих окон JavaScript, когда пользователь наводил указатель на вредоносные сообщения. Другие XSS-атаки на этот сайт перенаправляли пользователей на шпионский сайт или сайты, содержащие непотребный контент.

Профилактические меры

Для защиты от XSS-уязвимостей при разработке с помощью Ajax выполните следующие действия.

• Убедитесь, что переменные JavaScript взяты в кавычки.
• Используйте шестнадцатеричную кодировку JavaScript.
• Используйте кодировку Unicode JavaScript.
• Избегайте использования в коде обратной косой черты (\", \' или \\).
• Для грамматического разбора JSON используйте библиотеку JSON.parse или json2.js.
• Избегайте разбора JSON методом eval(), который выполняет любой сценарий JSON.

Ajax-мосты

Ajax-приложения предназначены для подключения к Web-сайту, на котором они размещены. В качестве меры безопасности приложение с сайта A не может подключиться к сайту В. Однако многие сайты для создания гибридных приложений используют сторонние Web-узлы и источники данных. Web-сервис моста Ajax действует как прокси-сервер, перенаправляющий трафик из сценариев JavaScript, исполняемых в браузере, на сторонний сайт, и наоборот. Используя Ajax-мост, сайт А может передавать данные или контент посетителям, приходящим с сайта В.

Мост не является особой уязвимостью, так же как Ajax - это не особая технология, а набор технологий. Ajax-мост увеличивает опасность, предоставляя злоумышленникам дополнительные возможности для атак. Такие атаки, как XSS и SQL-инъекции, могут передаваться через Ajax-мост. Сайт B может сделать все, чтобы защитить свои Web-приложения от угроз для посетителей, но для атаки на них будет использоваться сайт А ― с помощью Ajax-моста, который был проигнорирован.

Профилактические меры

Чтобы избежать уязвимости моста, требуется доверие среди сайтов, предоставляющих доступ с применением моста к сторонним сайтам. Нужно также проверить, как сторонние сайты обращаются к вашему Web-сайту, и выявить любые уязвимости, которые могут эксплуатироваться через мост.


Заключение

Сам по себе Ajax не создает никаких новых или уникальных уязвимостей. Не следует считать его менее безопасным, чем любой другой метод разработки Web-приложений. В этой статье мы рассмотрели некоторые уязвимости и угрозы, характерные для Ajax, а также соответствующие профилактические меры в процессе разработки программ.

На ранних стадиях разработки, при планировании будущего приложения, защита от уязвимостей должна быть приоритетной задачей. Частью стратегии Web-безопасности любой организации должно быть частое тестирование и сканирование.



08.08.2012
Джеффри Орлов, независимый технический писатель, независимый специалист
http://www.ibm.com/developerworks/ru/library/wa-vulnerabilities/index.html
http://www.ibm.com/developerworks/web/library/wa-vulnerabilities/index.html?S_TACT=105AGX99&S_CMP=CP

 

Konqi, да это так, переливание из пустого в порожнее и наоборот..
Читала это с неделю назад (дата древняя уже) и сейчас скопировала сюда чисто вместо комента в теме https://forum.antichat.ru/thread346765.html

Так что.. прошу прощение за неоправданные надежды заголовка и содержания..