TL; DR: Все хорошо написанные веб-сайты (/ приложения) должны испускать заголовок X-XSS-Protection: 0
и просто забыть об этой функции. Если вы хотите иметь дополнительную безопасность, которую могут обеспечить лучшие пользовательские агенты, используйте строгий Content-Security-Policy
заголовок.
Длинный ответ:
HTTP-заголовок X-XSS-Protection
- это одна из тех вещей, которые Microsoft представила в Internet Explorer 8.0 (MSIE 8), которая должна была повысить безопасность неправильно написанных веб-сайтов.
Идея состоит в том, чтобы применить некоторую эвристику, чтобы попытаться обнаружить отражение XSS-атаки и автоматически нейтрализовать атаку.
Проблемная часть этого - «эвристика» и «стерилизация». Эвристика вызывает ложные срабатывания, и стерилизация не может быть безопасно выполнена, поскольку она вызывает побочные эффекты, которые можно использовать для реализации атак XSS и DoS на совершенно безопасных веб-сайтах.
Плохо то, что если веб-сайт не X-XSS-Protection
отправляет заголовок, браузер будет вести себя так, как если бы заголовок X-XSS-Protection: 1
был отправлен. Хуже всего то, что это значение является наименее безопасным значением из всех возможных значений для этого заголовка!
Для данного защищенного веб-сайта (т. Е. На сайте отсутствуют отражающие XSS-уязвимости) эта функция «XSS-защиты» позволяет выполнять следующие атаки:
X-XSS-Protection: 1
позволяет злоумышленнику выборочно блокировать части JavaScript и поддерживать работу остальных сценариев. Это возможно, потому что эвристика этой функции просто «если значение какого-либо параметра GET найдено в части сценария источника страницы, сценарий будет автоматически изменен зависимым от агента пользователя способом». На практике злоумышленник может, например, добавить параметр, disablexss=<script src="framebuster.js"
и браузер автоматически удалит строку <script src="framebuster.js"
из фактического источника страницы. Обратите внимание, что остальная часть страницы продолжает работать, и злоумышленник только что удалил эту часть безопасности страницы. На практике любой JS в исходном коде страницы может быть изменен. В некоторых случаях страница без уязвимости XSS с отраженным содержимым может использоваться для запуска выбранного JavaScript на странице из-за стерилизацииневерное преобразование данных простого текста в исполняемый код JavaScript .
X-XSS-Protection: 1; mode=block
позволяет злоумышленнику утекать данные из источника страницы, используя поведение страницы в качестве побочного канала. Например, если страница содержит код JavaScript вдоль строк var csrf_secret="521231347843"
, злоумышленник просто добавляет дополнительный параметр, например, leak=var%20csrf_secret="3
и если страница НЕ заблокирована, 3
неправильная первая цифра. Атакующий пытается снова, на этот раз leak=var%20csrf_secret="5
загрузка страницы будет прервана. Это позволяет злоумышленнику узнать, что первая цифра секрета 5
. Затем злоумышленник продолжает угадывать следующую цифру.
В конце концов, если ваш сайт полон атак отражением XSS, использование значения по умолчанию 1
немного уменьшит поверхность атаки. Однако, если ваш сайт защищен и вы не излучаете X-XSS-Protection: 0
, ваш сайт будет уязвим любым браузером, который поддерживает эту функцию. Если вам нужна глубокая защита от браузеров от неизвестных уязвимостей XSS на вашем сайте, используйте строгий Content-Security-Policy
заголовок. Это не открывает ваш сайт для известных уязвимостей.
В настоящее время эта функция включена по умолчанию в MSIE, Safari и Google Chrome. Раньше это было включено в Edge, но Microsoft уже удалила эту ошибочную функцию из Edge . Mozilla Firefox никогда не реализовывал это.
Смотрите также:
https://homakov.blogspot.com/2013/02/hacking-facebook-with-oauth2-and-chrome.html
https://blog.innerht.ml/the-misunderstood-x-xss-protection/
http: / /p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf
https://www.slideshare.net/masatokinugawa/xxn-en
https://bugs.chromium.org/p/chromium/issues/detail?id=396544
https: // bugs.chromium.org/p/chromium/issues/detail?id=498982