Безопасность IE8: XSS-фильтр

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

Привет, я Дэвид Росс (David Ross), программный инженер безопасности в команде SWI. Я рад возможности написать гостевую статью в блоге IE, чтобы представить вам совместную работу, которую команда SWI провела с командой Internet Explorer.

Сегодня мы представляем информацию о новой функции IE8, которая делает реализацию (Type-1) XSS-атаки в Internet Explorer 8 намного более сложным заданием. XSS-утечки типа Type-1 составляют большую часть от всего количества объявленных уязвимостей, поэтому все чаще используются шутки ради или ради прибыли.

Количество сообщенных XSS-утечек на популярных сайтах в последнее время резко возросло - MITRE сообщают, что XSS-уязвимости на данный момент представляют самый часто публикуемый класс уязвимостей. Совсем недавно сайты типа XSSed.com начали собирать и публиковать десятки тысяч Type-1 XSS-уязвимостей, присутствующих на разнообразных сайтах.

XSS-уязвимости позволяют атакующему контролировать отношения между пользователем и сайтом или приложением, которому он доверяет. Межсайтовый скриптинг позволяет реализовать следующие типы атак: кража coockie, включая созданные на время одной сессии, что может привести к краже учетной записи; мониторинг введенных в сайт или приложение жертвы клавиатурных нажатий; проводить действия на сайте жертвы от имени пользователя-жертвы. Например, XSS-атака на сайт Windows Live Mail может позволить атакующему читать и пересылать письма, создавать новые события календаря и т.д.

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


XSS-фильтр: как это работает
XSS-фильтр работает как компонент IE8, который просматривает все запросы и ответы, проходящие через браузер. Когда фильтр обнаруживает XSS в межсайтовом запросе, он обнаруживает и нейтрализует атаку, если она зависит от ответа сервера. Пользователям не задают вопросы, на которые они не могут ответить - IE просто блокирует вредоносный скрипт от исполнения.

С новым XSS-фильтром пользователи IE8 Beta 2, которые столкнутся с Type-1 XSS-атакой, увидят примерно такое предупреждение.

Страница была модифицирована и XSS-атака была заблокирована. В данном случае XSS-фильтр обнаружил атаку межсайтового скриптинга в URL. Фильтр нейтрализировал атаку, так как идентифицированный скрипт отсылал данные на страницу ответа. В данном случае фильтр эффективен без модификации первоначального запроса к серверу или блокировки всего запроса.

Как можно понять, есть множество интересных и тонких сценариев, которые фильтр должен обрабатывать правильно. Вот некоторые из них.

• Фильтр должен быть эффективен, даже если атака направлена на артефакт часто используемых рабочих сред веб-приложений. Например, будет ли атака замечена, если определенный символ в запросе был потерян или модифицирован при повторном запросе?
• При фильтрации наш код не должен предоставить новый сценарий для атаки, которая бы отличалась от существующей. Например, представьте, что фильтр можно заставить нейтрализировать закрывающий тэг SCRIPT. В таком случае недоверенный контент с сайта позже может быть запущен как скрипт.

И, конечно, в дополнение ко всему этому нам нужно эффективно бороться со всеми векторами XSS-атак, которые еще не были закрыты другими способами сокращения поверхности для XSS-атаки.

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

Если функция Application Compatibility Logging в Internet Explorer включена, то всю активность XSS-фильтра можно просмотреть в Microsoft Application Compatibility Toolkit. Интернет-разработчики могут захотеть выключить фильтр для своего контента. Это можно сделать, поставив следующий HTTP заголовок: X-XSS-Protection: 0.

Наконец, мы используем очень прагматичный подход - мы решили создавать фильтр так, чтобы он не компрометировал совместимость сайта. Таким образом, XSS-фильтр защищает от самых распространенных XSS-атак, но он не является и никогда не будет панацеей от XSS-атак. Это похоже на прагматичный подход, используемый ASP.Net-запросом на авторизацию, хотя XSS-фильтр может быть намного агрессивней, чем функция ASP.Net.

Учитывая совсем незначительную несовместимость с сайтами и влияние на производительность, факт того, что наш фильтр эффективно блокирует часто используемый шаблон "><script>…, который мы часто видим в Type-1 XSS-атаках, является шагом вперед. Дальнейшее его развитие и при возможности блокировка других часто используемых XSS-атак, делает XSS-фильтр незаменимым элементом для обеспечения безопасности работы в сети.

Откинув предостережения, было бы интересно увидеть, как десятки тысяч Type-1 XSS-уязвимостей, проиндексированных на сайтах типа XSSed.com, перестанут работать в IE8. Не упоминаемые IFRAME SEO Poisoning атаки также будут блокироваться. В будещем я расскажу о принципе работы фильтра, его истории, ограничениях, и некоторых уроках, полученных во время его разработки.

Ну а пока рекомендуем ознакомиться с другими статьями из серии "Безопасность Internet Explorer 8":
Безопасность IE8: изменения в работе ActiveX
Безопасность IE8: технология защиты памяти DEP (NX)

Дэвид Росс,
инженер по программной безопасности Internet Explorer


Источник: http://blogs.msdn.com/ie
Перевод: Zloy Kak Pё$