Защита Internet Explorer 8. Анализ эффективности

Что такое XSS?

Наличие уязвимости "Межсайтовое выполнение сценариев" (Cross-site Scripting, XSS) позволяет атакующему передать серверу исполняемый код, который будет перенаправлен браузеру пользователя. Этот код обычно создается на языках HTML/Javascript, но могут быть использованы VBScript, ActiveX, Java, Flash, или другие поддерживаемые браузером технологии.

Переданный код исполняется в контексте безопасности (или в зоне безопасности) уязвимого сервера. Используя эти привилегии, код получает возможность читать, модифицировать или передавать важные данные, доступные с помощью браузера. У пользователя, в отношении которого производиться атака, может быть скомпрометирован аккаунт (кража cookie), его браузер может быть перенаправлен на другой сервер, или осуществлена подмена содержимого сервера. В результате тщательно спланированной атаки злоумышленник может использовать браузер жертвы для просмотра страниц приложения от имени атакуемого пользователя. Код может передаваться злоумышленником в URL, в заголовках HTTP запроса (Cookie, User-agent, Referrer), значениях полей форм и т.д.

Уязвимостям класса Cross-Site Scripting подвержено огромное количество Web-приложений. Это подтверждает как практика проводимых компанией Positive Technologies тестов на проникновение, так и независимые исследования. По данным исследования Web Application Security Consortium за 2007 год [1] самой распространенной уязвимостью является Cross-Site Scripting, эта уязвимость присутствует почти в 60% проанализированных сайтов (см. Рис. 1).

Рис. 1 Статистика WASC за 2007 г. "Процент уязвимостей от общего числа"

Продолжительное время степень риска, связанная с уязвимостями типа Cross-Site Scripting, недооценивалась. И лишь после многочисленных успешных атак с использованием XSS, а также с появлением Интернет-червей [2], способных размножаться путем эксплуатации уязвимостей Cross-Site Scripting, пришло осознание того, что необходимо как-то защищаться от подобной напасти.

И как с ним бороться?

Для борьбы с уязвимостью Cross-Site Scripting не достаточно только фильтровать данные, поступающие в Web-приложение со стороны пользователя. Например, уязвимость Cross-Site Scripting могла эксплуатироваться в контексте Web-сайта с помощью обращения к обычному PDF-документу [3], который содержится на этом Web-узле. Хотя существует множество полезных инструментов, которые помогают смягчить последствия XSS-атаки (например, Web Application Firewall), эти инструменты не удовлетворяют нуждам обычного пользователя по защите их самих от Cross-Site Scripting, когда они путешествуют в сети Интернет.

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

Так в новой версии Internet Explorer 8 появился XSS-фильтр, который делает реализацию XSS-атаки в нем намного более сложной задачей для злоумышленника. В настоящее время для скачивания доступна IE версии 8b2, собственно, про XSS-фильтр, реализованный в этой версии Интернет-браузера, и пойдет речь в данной статье. Логика работы фильтра описана в документе "IE 8 XSS Filter Architecture / Implementation", и за детальной информацией предлагается обращаться к первоисточнику [4]. Что же касается результатов работы, то при попытке передать на уязвимый сервер сакраментальный запрос:

http://www.example.com/script.asp?val=><script>alert("xss")</script>

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

Рис. 2 Реакция IE8 на проверку уязвимости Cross-Site Scripting

Методика исследования

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

В ходе исследования анализировалась применимость механизмов противодействия XSS, встроенных в Internet Explorer beta 2, для всех трех вариантов атаки. При этом использовались распространенные методы обхода XSS-фильтров, описанные в XSS Cheat List [7], и собственные разработки авторов. В ближайшее время планируется расширить XSS Cheat List особенностями Internet Explorer 8.0.

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

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

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

DOM-based XSS

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

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

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

Рис. 4 Эксплуатация DOM-based Cross-Site Scripting

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

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

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

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

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

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

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

Рис. 5 Уязвимый java-script код

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

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

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

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

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

Рис. 6 Эксплуатация внедрения java-script кода

Как часто можно встретить внедрение в код Javascript? Практика показывает, что подобные уязвимости - достаточно распространенное явление. По опыту авторов 10-15% Web-приложений, которые содержат уязвимости Cross-Site Scripting, будут содержать в том числе и уязвимость внедрения Javascript кода.

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

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

< img… $ XSS ….>

< font… $ XSS ….>

и т.п.

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

Рис. 7 Эксплуатация Cross-Site Scripting в тегах

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

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

<img… src=$XSS ….>

<font… size=$XSS ….>

< a… href=$ XSS ….>

и т.п.

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

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

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

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

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

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

Рис. 8 Эксплуатация Cross-Site Scripting совместно с HTTP Response Splitting

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

Заключение

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

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

Таблица 1. Фильтрация XSS в Internet Explorer 8 beta 2

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