XSS и политика безопасности контента
От чтения Шпаргалка по профилактике межсайтовых сценариев, Я знаю, что такое контекстно-зависимый выход.
В некоторых других моих проектах я использовал Zend_Escaper но мне интересно, достаточно ли использовать htmlspecialchars() предотвратить XSS, если я включил Content Security Policy, не позволяя unsafe-inline для JavaScript (скрипт) и CSS (стиль). На мой взгляд, это избавляет от контекстов JS и CSS внутри самого файла PHP.
Предположим, что мне не нужно выводить недоверенные данные HTML, только данные в HTML а также в атрибутах HTML.
Мне бы очень хотелось держаться подальше от шаблонных фреймворков, таких как Twig и Smarty.
Решение
Нет. CSP еще не поддерживается всеми браузерами. И многие используют старые браузеры. CSP на данный момент является хорошим бонусом для тех, кто использует приличные браузеры, и вы можете получать предупреждения из политики отчетов. Но не то, на что вы можете положиться.
Если у вас есть только пользователи с браузерами, поддерживающими CSP, CSP должен быть защищен от XSS с htmlspecialchars в php и экранировать все выходные данные, сделанные шаблонами javascript для всех выходных данных, если вы установили правильные политики. Это означает, что и unsafe-inline, и unsafe-eval не должны быть разрешены. Вы также должны ограничить хосты теми, с кем вы знаете, что загружаете ресурсы и которым доверяете. Используйте https только для вашего сайта и любого другого сайта, с которого вы загружаете ресурсы, и используйте HTTP Строгая Транспортная Безопасность избежать Человек посередине атаки.
Разрешить доступ к хостам iframe только на страницах, которые используют этот хост в iframe.
Отчеты с report-uri также необходимы, чтобы узнать, не были ли на вашем сайте какие-либо потенциальные атаки или будут проблемы с браузерами, не поддерживающими CSP.
Другие решения
Других решений пока нет …