Фильтр IE8 XSS: что он на самом деле делает?

В Internet Explorer 8 есть новая функция безопасности, XSS filter, которая пытается перехватить попытки межсайтового скриптинга. Это описано так:

Фильтр XSS, новый для Internet Explorer 8, обнаруживает JavaScript в URL-адресах и HTTP-сообщениях POST. Если JavaScript обнаружен, фильтр XSS ищет доказательства отражения, информацию, которая будет возвращена на атакующий веб-сайт, если запрос на атаку был отправлен без изменений. Если обнаружено отражение, фильтр XSS очищает исходный запрос, чтобы дополнительный JavaScript не мог быть выполнен.

Я нахожу, что фильтр XSS срабатывает даже тогда, когда нет "доказательств отражения", и я начинаю думать, что фильтр просто замечает, когда запрос отправляется на другой сайт, а ответ содержит JavaScript.

Но даже это трудно проверить, потому что эффект, похоже, приходит и уходит. IE имеет разные зоны, и когда я думаю, что воспроизвел проблему, фильтр больше не пинает, и я не знаю почему.

У кого-нибудь есть советы о том, как бороться с этим? Что фильтр действительно ищет? Есть ли способ для хорошего парня получить данные POST на стороннем сайте, который может вернуть HTML для отображения в iframe и не запускать фильтр?

Справочная информация. Я загружаю библиотеку JavaScript со стороннего сайта. Этот JavaScript собирает некоторые данные с текущей HTML-страницы и отправляет его на сторонний сайт, который отвечает некоторым HTML-кодом, отображаемым в iframe. Чтобы увидеть его в действии, перейдите на страницу

Ответ 1

Что это на самом деле? Это позволяет третьим сторонам ссылаться на испорченную версию вашего сайта.

Он срабатывает, когда [выполняется несколько условий, и] он видит строку в представлении запроса, которая также существует дословно на странице и которая, по ее мнению, может быть опасной.

Предполагается, что если <script>something()</script> существует как в строке запроса, так и в коде страницы, то это должно быть потому, что ваша серверная сторона script является небезопасной и отражает эту строку прямо в качестве разметки без экранирования.

Но, конечно же, помимо того факта, что это совершенно правильный запрос, который кто-то мог набрать, совпадающий по совпадению, он также настолько близок, что они совпадают, потому что кто-то посмотрел на страницу и намеренно скопировал ее часть. Например:

http://www.bing.com/search?q=%3Cscript+type%3D%22text%2Fjavascript%22%3E

Следуйте этому в IE8, и я успешно саботировал вашу страницу Bing, чтобы она давала ошибки script, а биты вывода всплывающих окон не работали. По сути, это дает злоумышленнику, чья ссылка получает лицензию на выбор и отключение частей страницы, которые ему не нравятся, - и это может включать в себя другие связанные с безопасностью меры, такие как сценарии framebuster.

Что IE8 считает "потенциально опасным? Намного больше и намного страннее, чем этот тег script. например. Более того, похоже, он соответствует набору "опасных шаблонов" с использованием системы текстовых шаблонов (предположительно, регулярного выражения) вместо любого вида парсера HTML, такого как тот, который в конечном итоге проанализирует страницу. Да, используйте IE8, а ваш браузер - pařṣing HT ̈́͜ ML w ̧̼̜ it ̏̔ h ͙r̿e ̴̬ g ̉̆ e͎x ͍͔̑̃̽̚.

'Защита XSS путем просмотра строк в запросе полностью поддельна. Он не может быть "исправлен; сама концепция по своей сути ошибочна. Помимо проблемы входа в систему, когда она не нужна, она никогда не сможет защитить вас от всего, кроме самых простых атак, и злоумышленники наверняка обойдутся такими блоками, как IE8 станет более широко использоваться. Если вы забыли забыть свой вывод HTML, вы все равно будете уязвимы; все" защита "XSS может предложить вам ложное чувство безопасности. К сожалению, Microsoft, похоже, любит это ложное чувство безопасности; в ASP.NET существует аналогичная" защита" XSS, на стороне сервера.

Итак, если у вас есть ключ к созданию webapp-авторинга, и вы правильно выбрали вывод в HTML, как хороший мальчик, определенно неплохо было бы отключить это нежелательное, неработоспособное, неправильное вторжение, выведя заголовок:

X-XSS-Protection: 0

в ваших ответах HTTP. (И используя ValidateRequest="false" на ваших страницах, если вы используете ASP.NET.)

Для всех остальных, кто все еще строит строки вместе на PHP, не заботясь о правильном кодировании... ну, вы также можете оставить его. Не ожидайте, что он действительно защитит ваших пользователей, но ваш сайт уже сломан, поэтому кто заботится, если он сломается немного больше, не так ли?

Чтобы увидеть его в действии, перейдите на страницу AOL Food и нажмите значок "Печать" чуть выше истории.

А, да, я вижу это нарушение в IE8. Не сразу видно, где IE сделал взломать содержимое, которое остановило его выполнение, хотя... единственный междоменный запрос я вижу, что кандидат для фильтра XSS - это http://h30405.www3.hp.com/print/start:

POST /print/start HTTP/1.1
Host: h30405.www3.hp.com
Referer: http://recipe.aol.com/recipe/oatmeal-butter-cookies/142275?

csrfmiddlewaretoken=undefined&characterset=utf-8&location=http%253A%2F%2Frecipe.aol.com%2Frecipe%2Foatmeal-butter-cookies%2F142275&template=recipe&blocks=Dd%3Do%7Efsp%7E%7B%3D%25%3F%3D%3C%28%2B.%2F%2C%28%3D3%3F%3D%7Dsp%[email protected]%3D%25%3F%3D%7E%7C%7Czqk%7Cpspm%3Db3%3Fd%3Do%7Efsp%7E%7B%3D%25%3F%3D%3C%7D%2F%27%2B%2C.%3D3%3F%3D%7Dsp%[email protected]%3D%25%3F%3D%7E%7C%7Czqk...

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

Чтобы исправить это, HP необходимо сделать сервер на h30405.www3.hp.com, включите заголовок X-XSS-Protection: 0.

Ответ 2

Вы должны отправить мне (ericlaw @microsoft) сетевой захват (www.fiddlercap.com) сценария, который, по вашему мнению, неверен.

Фильтр XSS работает следующим образом:

Включен ли XSSFILTER для этого процесса?
Если да - переходите к следующей проверке Если нет - обход XSS-фильтра и продолжить загрузку
Является ли загрузка "документа" (например, фрейм, а не подзаголовком)? Если да - переходите к следующей проверке Если нет - обход XSS-фильтра и продолжить загрузку
Это HTTP/HTTPS-запрос? Если да - переходите к следующей проверке Если нет - обход XSS-фильтра и продолжить загрузку
Включает ли RESPONSE заголовок защиты x-xss? Да: Значение = 1: включен фильтр XSS (проверка urlaction отсутствует) Значение = 0: Фильтр XSS отключен (проверка urlaction отсутствует) Нет: перейти к следующей проверке.
Является ли загрузка сайта в зоне, где URLAction разрешает фильтрацию XSS? (По умолчанию: Интернет, Надежный, Ограниченный) Если да - переходите к следующей проверке Если нет - обход XSS-фильтра и продолжить загрузку
Это запрос на перекрестный сайт? (Заголовок Referrer: соответствует ли окончательное (пост-перенаправленное) доменное имя в заголовке реферера HTTP-запроса совпадающему с полным доменным именем возвращаемого URL-адреса?) Если да - обход XSS-фильтра и продолжить загрузку Если нет - тогда URL-адрес в запросе должен быть кастрирован.
Указывает ли эвристическое указание данных RESPONSE на небезопасные данные запроса? Если да - измените ответ.

Теперь точные детали # 7 довольно сложны, но в основном вы можете представить, что IE выполняет сопоставление данных запроса (URL/Post Body) с данными ответа (тела script), и если они совпадают, то данные ответа будут изменены.

В случае вашего сайта вы захотите посмотреть на тело POST на http://h30405.www3.hp.com/print/start и соответствующий ответ.

Ответ 3

На самом деле это хуже, чем может показаться. Фильтр XSS может сделать безопасные сайты небезопасными. Читайте здесь: http://www.h-online.com/security/news/item/Security-feature-of-Internet-Explorer-8-unsafe-868837.html

Из этой статьи:

Однако Google отключает фильтр IE XSS, отправив заголовок X-XSS-Protection: 0, что делает его невосприимчивым.

Я не знаю достаточно о вашем сайте, чтобы судить, может ли это быть решением, но вы, вероятно, можете попробовать. Более подробно, техническое обсуждение фильтра и его отключить можно здесь: http://michael-coates.blogspot.com/2009/11/ie8-xss-filter-bug.html