Безопасность в Веб-разработке
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().
Источник: Защита Internet Explorer 8. Анализ эффективности [21]
Тогда, несмотря на фильтр XSS в IE8, возможно успешно провести атаку Cross-Site Scripting (рис. 17.7).
Источник: Защита 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.
Источник: Защита 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 позволяют значительно снизить количество успешных атак с использованием данного вектора.