Политика безопасности XSS и контента

Читая шпаргалку по предотвращению XSS (межсайтовый скриптинг), я осведомлены о том, что такое экранирование с учетом контекста.

В некоторых других своих проектах я использовал Zend_Escaper, но мне интересно, достаточно ли этого для использования htmlspecialchars() для предотвращения XSS, если я включил политику безопасности контента без разрешения _ 2_ для JavaScript (скрипт) и CSS (стиль). На мой взгляд, это избавляет от контекстов JS и CSS внутри самого файла PHP.

Предположим, мне не нужно выводить ненадежные данные HTML, только данные в HTML и в атрибутах HTML.

Мне бы очень хотелось держаться подальше от таких фреймворков для создания шаблонов, как Twig и Smarty.


person rink.attendant.6    schedule 13.10.2014    source источник


Ответы (1)


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

Если у вас есть только пользователи с браузерами с включенным CSP, CSP должен быть защищен от XSS с htmlspecialchars в php и экранировать весь вывод, сделанный шаблонами javascript для всего вывода, если вы правильно настроили политики. Это означает, что нельзя допускать как unsafe-inline, так и unsafe-eval. Вам также следует ограничить хосты теми, с которых вы загружаете ресурсы и которым доверяете. Используйте только https для своего сайта и любого другого сайта, с которого вы загружаете ресурсы, и используйте HTTP Strict Transport Security чтобы избежать атак Man In The Middle.

Разрешить доступ только к хостам iframe на страницах, которые используют этот хост в iframe.

Отчеты с report-uri также необходимы, чтобы узнать, подвергался ли ваш сайт потенциальным атакам или будут ли проблемы для браузеров без поддержки CSP.

Дополнительная информация здесь и здесь.

person OIS    schedule 18.10.2014
comment
Хорошо, но как насчет браузеров, которые поддерживают CSP? - person rink.attendant.6; 18.10.2014
comment
Ву, это первый раз, когда я слышал о report-uri… звучит немного опасно как концепция, потому что она наверняка вызовет «DDoS-атаки», наводняя владельца сайта мошенническими отчетами, ведущими к спам-сайтам, или просто для создания дополнительных (ручных) усилия по проверке этих отчетов… - person CBroe; 18.10.2014
comment
report-url действительно ужасен и наводняет владельцев сайтов, но это не из-за атак, а из-за плохо написанных плагинов браузера. Некоторые плагины могут индивидуально генерировать сотни предупреждений, которые являются законными, но это вина плагина, а не чего-либо, что владелец сайта может контролировать. - person anthonyryan1; 27.04.2015