Безопасность в Веб-разработке

17.2.2. Исследование эффективности XSS Filter

Большинство исследователей выделяет три типа уязвимостей и атак, связанных с XSS: постоянные (сохраненные, persistent, stored, Type-2), непостоянные (отраженные, non-persistent, reflected, Type-1) [12] и DOM-based XSS (Type-3) [20]. Основным отличием между ними заключается в том, что в отраженном варианте передача кода серверу и возврат его клиенту осуществляется в рамках одного HTTP-запроса, а в сохраненном – может происходить и в разных запросах. Осуществление непостоянной атаки требует, чтобы пользователь перешел по ссылке, сформированной злоумышленником (ссылка может быть передана по email, ICQ и т.д.). В процессе загрузки сайта код, внедренный в URL или в заголовки запроса, будет передан клиенту и выполнен в его браузере. Сохраненная разновидность уязвимости возникает, когда код передается серверу и сохраняется на нем на некоторый промежуток времени. Наиболее п опулярными целями атак в этом случае являются форумы, почта с Веб-интерфейсом и чаты. Для атаки пользователю не обязательно переходить по ссылке, достаточно посетить уязвимый сайт. Третий тип XSS (DOM-based) может присутствовать как в сохраненном, так и в отраженном варианте, но выделяется тем, что внедрение кода осуществляется с использованием AJAX-технологий (например, JavaScript document.write и т.д.).

В ходе исследования анализировалась применимость механизмов противодействия XSS, встроенных в Internet Explorer 8, для всех трех вариантов атаки [21].

17.2.2.1. Сохраненный вариант

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

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

17.2.2.2. DOM-based XSS

DOM-based XSS уязвимость данного типа возникает, когда внедрение кода динамически осуществляется с использованием Javascript и AJAX-технологий. Эксперименты показали, что фильтр XSS в Intenet Explorer 8 реализует защиту от большинства сценариев данного типа атак, но в некоторых случаях логику фильтра можно обойти. Примерами являются операторы выполнения скриптов напрямую (eval), изменение URL документа (document.location) и т.д. На рис. 17.6 приведен пример уязвимого приложения, использующего клиентский Javascript для выполнения кода напрямую через метод eval().

Рис. 17.6. Уязвимый код Веб-приложения на языке PHP

Источник: Защита Internet Explorer 8. Анализ эффективности [21]

Тогда, несмотря на фильтр XSS в IE8, возможно успешно провести атаку Cross-Site Scripting (рис. 17.7).

увеличить изображение
Рис. 17.7. Эксплуатация DOM-based Cross-Site Scripting

Источник: Защита Internet Explorer 8. Анализ эффективности [21]

В других распространенных случаях, когда Javascript используется для записи в код HTML-страницы или изменения DOM-объектов напрямую, атака блокируется фильтром.

17.2.2.3. Отраженный вариант

Можно выделить четыре основных ситуации, в которых возможен отраженный вариант атаки Межсайтовое выполнение сценариев:

• внедрение кода в Javascript;
• внедрение кода в тег;
• внедрение кода в параметр тега;
• внедрение кода в HTML.

Далее рассмотрено противодействие Internet Explorer в каждом их этих случаев.

17.2.2.3.1. Внедрение кода в Javascript

Данная ситуация очень схожа с DOM-based XSS. Однако код внедряется непосредственно в блок Javascript без использования функций AJAX. Пример уязвимого кода приведен на рис. 17.8.

Рис. 17.8. Уязвимый Javascript код

Источник: Защита Internet Explorer 8. Анализ эффективности [21]

В этом случае злоумышленник может передать в качестве значения параметра XSS -значение:

500); alert(document.cookie);//

В результате код в странице приобретет вид:

setTimeout("writetitle()", 500); alert(document.cookie);//)

Два символа обратного слеша является комментарием в языке Javascript, поэтому, с точки зрения синтаксиса, здесь все верно. Таким образом, несмотря на фильтр XSS в IE8, возможно успешно провести классическую атаку Cross-Site Scripting.

17.2.2.3.2. Внедрение кода в тег

Данный вариант уязвимости встречается редко, но сбрасывать его со счетов не стоит. Фильтр XSS в Internet Explorer пропускает конструкции, когда уязвимый параметр к Cross-Site Scripting встречается в следующих вариациях:

<img… $XSS ….>
<font… $XSS ….>
и т.п.

То есть в ситуациях, когда уязвимое значение включено в тег и не является параметром этого тега. В этом случае можно использовать обработчики событий Javascript (onClick(), onMouseover()) для передачи управления коду, используемому для атаки.

17.2.2.3.3. Внедрение кода в параметр тега

Данная ситуация является одним из самых распространенных случаев XSS. Она возникает, когда уязвимый параметр к Cross-Site Scripting встречается в параметре тега:

<img… src=$XSS ….>
<font… size=$XSS ….>
<a… href=$XSS ….>
и т.п.

Тестирование показало, что фильтр Internet Explorer прекрасно справляется с данным видом атак.

17.2.2.3.4. Внедрение кода в HTML

Классическая ситуация, в которой внедрение происходит непосредственно в HTML, и для проведения атаки необходимо открыть тег. И в этом случае фильтр Internet Explorer показал себя с лучшей стороны, отфильтровав все опробованные комбинации и кодировки.

17.2.2.3.5. Использование расщепления HTTP-ответа

Для тех разработчиков Веб-приложений, которые захотят отключить фильтр XSS на своих сайтах, в Internet Explorer подобная возможность предусмотрена путем установки HTTP-заголовка "X-XSS-Protection: 0" в возвращаемом Веб-сервером ответе.

Однако это можно использовать для обхода фильтра XSS. Такая возможность возникает, когда приложение уязвимо для XSS и для уязвимости типа "Расщепление HTTP-ответа" (HTTP Response Splitting). Используя расщепление, злоумышленник может внедрить дополнительный HTTP-заголовок, который будет отключать фильтр XSS, и эксплуатировать уязвимость.

Не смотря на то, что подобная ситуация встречается не часто, ее тоже необходимо учитывать. По статистике Web Application Security Consortsium, ручной анализ позволяет идентифицировать HTTP Response Splitting в 7,75% всех приложений.

17.2.2.4. Заключение

Исследование механизма противодействия атакам "Межсайтовое выполнение сценариев", встроенного в браузер Internet Explorer 8, показало, что подход защиты от Cross-Site Scripting на стороне клиента может быть достаточно эффективным в борьбе с отраженным вариантом XSS. К сожалению, решить проблему с сохраненным типом атаки лишь на стороне клиента в настоящее время не представляется возможным (отключение Javascript и прочих активных объектов – это не решение проблемы), поэтому это тема лежит за рамками поддерживаемого функционала XSS -фильтра в IE8. Кроме того, не поддерживается фильтрация некоторых DOM-based атак, которые весьма актуальны в современном мире AJAX и Веб 2.0. Неплохим расширением функций фильтра была бы фильтрация атак типа HTTP Response Splitting, что позволило бы избежать некоторых методов обхода фильтра.

Сводная таблица возможностей Internet Explorer 8 в части фильтрации XSS приведена в табл. 17.1 [21].

Учитывая, что отраженный вариант XSS является самым распространенным типом уязвимостей этого типа, возможности Internet Explorer позволяют значительно снизить количество успешных атак с использованием данного вектора.

17.2.3. Ключевые термины

XSS, Сross Site Sсriрting, XSS Filter.