Защита 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 может заблокировать выполнения атаки в первой паре запрос-ответ (например, при создании сообщения в форуме). Однако все последующие запросы (например, просмотр форума), а, соответственно, и атаки проходят успешно.