Заголовок политики безопасности контента (CSP): для каждого файла или только для реальных HTML-страниц?

Question

В настоящее время я добавляю заголовок Content Security Policy (CSP) в наше приложение. Мне интересно, к каким файлам должен быть прикреплен заголовок. После некоторых исследований я не нашел четкого ответа на него.

Twitter, например только добавил это к фактическому документу HTML. Однако Facebook добавил его почти к каждому ресурсу и документу HTML (HTML, JS, CSS и т. Д.).

Итак, нужно ли добавлять заголовок Политики безопасности контента в каждый обслуживаемый файл ресурсов или только в HTML-документ? Как это работает с запросами Ajax (контент JSON)? Как это работает с SPA (только файл index.html или все ресурсы)? Я не хочу замедлять страницу, добавляя длинные заголовки CSP в каждый файл, если это не нужно с точки зрения безопасности.

EDIT:

Чтобы уточнить: браузер по-разному относится к изображениям или другим ресурсам, не относящимся к документам, если они имеют прикрепленный заголовок CSP?

Answer 1

Браузеры, поддерживающие заголовок ответа HTTP Content Security Policy , будут препятствовать загрузке изображений (и другого содержимого) для любой страницы, где заголовок ответа или метатег содержит директивы Content Security Policy, ограничивающие рассматриваемые домены. в качестве допустимых источников содержимого требуется загрузка всего содержимого через HTTPS и т. д. Наиболее широко используемые современные браузеры поддерживают политику безопасности содержимого и применяют ее для управления большинством ресурсов содержимого (включая изображения), связанных с любым запросом HTTP. (за исключением того, что управление ресурсами веб-работника не поддерживается в Safari и IE и может не поддерживаться в Edge или Opera).

Вы можете специально включить директивы политики img-src в свою Политику безопасности контента, чтобы ограничить домены, считающиеся допустимыми источниками для изображений, а также требовать схему HTTPS и т. Д. Существуют также специальные директивы для множество других ресурсов, включая шрифты, фреймы, мультимедиа (аудио, видео и т. д.), скрипты, таблицы стилей, веб-работники и т. д.

Вам нужно будет либо включить свою Политику безопасности контента как часть заголовка ответа HTTP, который возвращается с вашего веб-сервера, как часть каждого HTTP-запроса, где вы хотите ограничить допустимые источники контента, либо убедиться, что запрашиваемая страница содержит контент Метатег политики безопасности, например ...

<meta http-equiv="Content-Security-Policy" content="default-src 'self';">

Обратите внимание, что браузеры IE 10+ поддерживают заголовки ответов Content Security Policy, но не метатеги (также есть некоторые конкретные детали реализации, которые необходимо учитывать, если вы хотите поддерживать IE).

Answer 2

замедлить страницу, добавив длинные заголовки CSP к каждому файлу

Предположительно, со статусом 304 Не изменено - заголовки CSP не отправляются
- только при начальной загрузке

Answer 3

CSP не предназначен в качестве первой линии защиты от уязвимостей, связанных с внедрением контента.

...

Новый ответ II

Вопрос:

Чтобы уточнить: браузер по-разному относится к изображениям или другим ресурсам, не относящимся к документам, если они имеют прикрепленный заголовок CSP?

Мой ответ:

• Сначала определите « non-document »? W3 (ребята, которые задают, как на самом деле работает интернет) имеют определение "документа" , и я предполагаю, что ваше определение такое же.

  Если это не так, пожалуйста, уточните соответственно.

Правила W3 по политике безопасности контента (по состоянию на октябрь 2018 г.) гласят, что цели CSP заключаются в следующем:

• Снижение риска атак с внедрением контента, предоставляя разработчикам достаточно детальный контроль над:

  • Ресурсы, которые могут быть запрошены (и впоследствии внедрены или выполнены) от имени конкретного Документа или Работника

  • Выполнение встроенного скрипта

  • Динамическое выполнение кода (через eval () и аналогичные конструкции)

  • Применение встроенного стиля

• Снижение риска атак, требующих внедрения ресурса во вредоносный контекст (описана атака «Pixel Perfect») в [TIMING], например), предоставляя разработчикам детальный контроль над источники, которые могут встраивать данный ресурс.

• Предоставляет структуру политики, которая позволяет разработчикам снижать привилегии своих приложений.

• Предоставляет механизм отчетности, который позволяет разработчикам обнаруживать недостатки, эксплуатируемые в дикой природе.

Примечание пункт 1 (i);

"Ресурсы, которые могут быть запрошены (и впоследствии внедрены или выполнены) от имени определенного Документа или Работника "

Документ определен, как указано выше, а работа определена, по сути, как то, что использует модель DOM Javascript (, это может быть неправильно ).

Таким образом, CSP, как ожидается, будет применять к документам (данные) и работникам .

Другие (MP3, PDF и т. Д.) Файлы - документы или рабочие? Они не являются документами, но то, как они обрабатываются в браузерах , подразумевает, что они содержатся в структуре документа .

Пожалуйста, посмотрите это old Chrome Bug report . При этом PDF-файл не смог загрузить содержимое из-за настроек CSP веб-сайтов, а PDF-файл фактически загружался плагином для браузера (родным для всех современных браузеров) и поэтому был подвержен влиянию object-src CSP.

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

Следовательно: браузеры НЕ ТРЕБУЮТСЯ для применения CSP к недокументированным и нерабочим объектам, но из-за того, как работают браузеры, они, вероятно, будут применять заголовки CSP к недокументированным и нерабочим объектам факт, что эти объекты будут обернуты в модели документов для облегчения работы с файлами в браузере.

Но Это происходит из-за кодирования браузера и не должно ожидаться с октября 2018 года.