на чем основана csp v2
Content Security Policy (CSP)
CSP разрабатывался с возможностью полной обратной совместимости (за исключением CSP version 2, в которой были намеренно определены некоторые противоречия блокирующие обратную совместимость; с деталями можно ознакомиться здесь, в пункте 1.1). Браузеры, которые не поддерживают CSP, все ещё могут работать с серверами, которые поддерживают CSP, и наоборот: браузеры, в которых поддержка CSP отсутствует, будут её игнорировать, продолжая работу в соответствии со стандартными правилами ограничения домена для загрузки контента. В случае, если сайт не предоставляет CSP-заголовки, браузеры, в свою очередь, будут использовать стандартные правила ограничения домена.
Угрозы
Межсайтовый скриптинг
Основная цель создания CSP заключается в устранении XSS-атак и сборе данных об их попытках. XSS-атаки используют доверие браузера к контенту, полученному с сервера. Зловредные скрипты исполняются в браузере жертвы, поскольку браузер доверяет источнику, даже когда скрипт поставляется не оттуда, откуда кажется.
CSP даёт возможность администраторам серверов снизить или полностью устранить вектора, по которым злоумышленники могут провести XSS, с помощью определения доменов, которые браузер клиента должен считать доверенными источниками исполняемых скриптов. В таком случае, браузер, совместимый с CSP, будет исполнять только те скрипты, которые были получены из списка разрешённых источников, и игнорировать прочие (в т.ч. встраиваемые скрипты и обработчики событий, указанные непосредственно в HTML-атрибутах).
В качестве крайней меры защиты, сайты, которые хотят запретить исполнение скриптов, могут настроить это поведение глобально, с помощью соответствующей опции.
Пакетный сниффинг
В дополнение к ограничению количества доверенных доменов, с которых разрешается получать контент, можно также ограничить список используемых протоколов; например (в идеале и это крайне желательно с точки зрения обеспечения безопасности), сервер может поставить ограничение на получение контента только по HTTPS. Завершённая стратегия защиты передачи данных должна включать в себя не только принуждение к использованию HTTPS, но также и пометку всех кук с помощью специального флага, а также перенаправление запросов с HTTP на HTTPS. Сайты также могут использовать Strict-Transport-Security HTTP-заголовок, чтобы обеспечить подключение к ним браузеров только по защищённому каналу.
Использование CSP
Настройка CSP включает в себя добавление на страницу HTTP-заголовка Content-Security-Policy (en-US) и его настройку в соответствии со списком доверенных источников, из которых пользователь может получать контент. Например, страница, на которой происходит загрузка и отображение изображений может разрешать их получение из любых источников, но ограничить отправку данных формы конкретным адресом. При правильной настройке, Content Security Policy поможет защитить страницу от атак межсайтового скриптинга. Данная статья описывает как правильно настроить необходимые заголовки и примеры, как это сделать.
Определение политики
Вы можете начать настройку Content-Security-Policy (en-US) с определения HTTP-заголовка и указания какую политику использовать:
Создание политики
Примеры: Распространённые случаи применения
В данном разделе приводятся наиболее распространённые сценарии использования CSP.
Пример 1
Вы хотите ограничить источники контента только исходным сервером (исключая поддомены)
Пример 2
Вы хотите разрешить получение контента с доверенного домена и всех его поддоменов (доверенный домен не обязательно должен совпадать с тем, на котором настраиваются CSP.)
Пример 3
Вы хотите разрешить пользователям приложения вставлять в создаваемый ими контент картинки из любого источника, но при этом ограничить источники аудио- и видео-файлов списком доверенных провайдеров. Получение скриптов должно происходить только с конкретного сервера, содержащего доверенный код.
При такой настройке, весь контент доступен для получения только с исходного домена, со следующими исключениями:
Пример 4
Вы хотите удостовериться, что весь получаемый контент для онлайн-банкинга идёт по SSL и атакующий не сможет обрабатывать запросы:
Пример 5
Для просмотра писем в почтовом клиенте вы хотите разрешить использование HTML внутри письма, а также позволить загрузку изображений из любых источников, но запретить использование любого JavaScript-кода и прочий потенциально опасный контент.
Заметьте, что в настройке политики отсутствует директива script-src (en-US); при такой настройке CSP при загрузке скриптов будут использоваться настройки, определяемые директивой default-src (en-US), следовательно все скрипты могут быть загружены только с исходного домена.
Тестирование настройки политики
Для облегчения развёртывания можно настроить развёртывание CSP в режиме report-only. Таким образом, политика не будет ограничивать загрузку, но будет сообщать обо всех нарушениях на указанный в заголовке URI. Кроме того, заголовок report-only может использоваться для тестирования новой политики без полноценного развёртывания.
Для определения вашей политики вы можете использовать заголовок Content-Security-Policy-Report-Only (en-US) следующим образом:
Настройка отправки отчётов
По умолчанию, отправка отчётов не производится. Для того чтобы включить отправку отчётов, необходимо в вашей политике определить директиву report-uri (en-US) и указать как минимум один URI, куда будут направляться отчёты:
Кроме того, необходимо настроить свой сервер на получение этих отчётов; вы можете хранить и обрабатывать эти отчёты как считаете нужным.
Синтаксис отчёта о происшествиях
Объект отчёта в формате JSON содержит следующие поля:
Пример отчёта о происшествии
Совместимость с браузерами
BCD tables only load in the browser
Для некоторых версий Safari существует специфическая несовместимость реализации CSP. Если установить заголовок Content Security Policy без заголовка Same Origin, то браузер начнёт блокировать и создавать ложно-положительные отчёты о нарушении политики для всего контента, как с запрашиваемого источника, так и из внешних источников.
Content-Security-Policy
The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. With a few exceptions, policies mostly involve specifying server origins and script endpoints. This helps guard against cross-site scripting attacks (Cross-site_scripting).
For more information, see the introductory article on Content Security Policy (CSP).
| Header type | Response header |
|---|---|
| Forbidden header name | no |
Syntax
consists of: with no internal punctuation.
Directives
Fetch directives
Fetch directives control the locations from which certain resource types may be loaded.
Restricts the URLs which can be loaded using script interfaces
Serves as a fallback for the other fetch directives.
Specifies valid sources of images and favicons.
Specifies valid sources of application manifest files.
Note: Elements controlled by object-src are perhaps coincidentally considered legacy HTML elements and are not receiving new standardized features (such as the security attributes sandbox or allow for ). Therefore it is recommended to restrict this fetch-directive (e.g., explicitly set object-src ‘none’ if possible).
Specifies valid sources to be prefetched or prerendered.
Как настроить Content Security Policy (CSP)
Три года назад организацией Mozilla Foundation был разработан новый стандарт политики безопасности, который предотвращает XSS-атаки и другие, связанные с ним виды атак запрещая подгружать и выполнять скрипты с запрещённых ресурсов. Называется он Content Security Policy (CSP), что в переводе означает «Политика безопасности контента».
На момент написания статьи стандарт CSP находится в статусе Candidate Recommendation, что означает возможное принятие этого стандарта в будущем W3C консорциумом. На данный момент все популярные браузеры поддерживают этот стандарт.
| Браузер | Версия | Примечания |
|---|---|---|
| Chrome | 25+ | Полная поддержка |
| Firefox | 23+ | |
| Opera | 15+ | |
| Яндекс.Браузер | ||
| Firefox | 4-22 | Поддерживают нестандартный заголовок X-Content-Security-Policy и частично поддерживают стандартный |
| IE | 10+ | |
| Chrome | 14-24+ | Поддерживают нестандартный заголовок X-Webkit-CSP и частично поддерживают стандартный |
| Safari | 5-7 | |
Как отсутствие CSP может навредить сайту?
Допустим у вас есть сайт, на котором вы показываете рекламу пользователям и честно зарабатываете деньги. И всё идёт хорошо, пока к вам не начнут ходит пользователи с заражёнными браузерами. Заражённый браузер будет подменять рекламу на вашем сайте на свою и показывать её пользователю. Как следствие — пессимизация со стороны поисковиков и падение дохода. Если же вы введёте политику CSP на своём сайте, то чужая реклама уже не покажется конечному пользователю, потому что сервер с которого реклама будет пытаться загрузиться находится не в белом списке, впрочем обо всё по порядку.
Содержание Content Security Policy
По сути Content Security Policy — это заголовок, который сервер отправляет браузеру. Давайте разберём более детально из чего же он состоит.
| Директива | Назначение |
|---|---|
| default-src | В этой директиве задаются белые списки хостов, которые будут автоматически присвоены не заданным директивам. |
| script-srс | Белый список хостов с которых разрешается загрузка javascript |
| style-src | Белый список хостов с которых разрешается загрузка css |
| object-src | Белый список хостов с которых разрешается загрузка Flash-подобных плагинов |
| img-src | Белый список хостов с которых разрешается загрузка картинок |
| media-src | Белый список хостов с которых разрешается загрузка аудио и видео |
| frame-src | Белый список хостов с которых разрешается загрузка iframe’ов |
| font-src | Белый список хостов с которых разрешается загрузка шрифтов |
| connect-src | Специальные директивы для XMLHttpRequest, WebSocket и EventSource. Обратите внимание, что для каждой из этих директив задаётся список не урлов, а хостов, с которыми разрешено общаться браузеру. |
| report-uri | Url, на который будет отсылаться JSON-отчёт о нарушениях политики. Пример отчёта будет показан ниже в статье. |
Сейчас ещё немного теории, и потом сразу перейдём к практики, потерпите 😉
Устанавливаем Content Security Policy на сайт
Как я уже писал выше, CSP — это обычный http заголовок, который можно наблюдать в консоли Google Chrome, наряду с остальными заголовками:
Чтобы лучше понять как работает Content Security Policy, давайте немного поэкспериментируем. Создайте файл index.php и напишите в него следующий код:
Обратите внимание, что в http заголовке я указал Content-Security-Policy-Report-Only он аналогичен Content-Security-Policy, с той лишь разницей, что не блокирует ресурсы, а только оповещает о нарушении. Крайне полезная штука при тестировании системы перед внедрением!
Т.е. попробуем выполнить инлайн скрипт и загрузить картинку со стороннего хоста. И посмотрим как отреагирует наш бравый защитник: 
CSP отреагировал адекватно. Т.е. подгрузил картинку и выполнил инлайновый javascript, но при этом сказал нам в консоли «ата-та!», а именно: сообщил о том, что произошло два нарушения.
Теперь давайте изменим заголовок с Content-Security-Policy-Report-Only на Content-Security-Policy и посмотрим что будет: 
Пендальф CSP никого не пустил. 
Инлайн скрипт не был выполнен, а картинка не загрузилась. Круто, правда?
Теперь можете поэкспериментировать самостоятельно. Вам пригодятся две таблички выше в статье, в которых мы рассмотрели директивы и ключевые слова для указания хостов. Попробуйте заменить ‘self’ на https://zabolotskikh.com/ и посмотрите что произойдет — картинка сможет загрузиться, так как её сервер был указан в белом списке.
Обработка отчётов
Вся прелесть этой политики в том, что помимо блокирования, мы также можем собирать отчёты о нарушениях! Помните в примере в http заголовке мы указали url report-uri http://localhost/csp/collector.php для сбрасывания отчётов? Как не сложно догадаться на этот url будут отправляться все отчёты о нарушениях.
Вот так выглядит отчёт о нарушении (в формате JSON):
С этим отчётом вы можете делать всё что угодно, например сохранять в базу, отправлять на почту. Я предлагаю записывать все нарушения в csv файл. Давайте сделаем это!
Создайте файл collector.php и напишите в него следующие строки:
Теперь ещё раз обновите страницу и посмотрите в директорию http://localhost/csp/. У вас должен появиться файл report.csv с двумя строчками кода: 
Ура! Мы поймали отчёт о нарушениях и записали его в файл. Можете показать этот файл друзьям 😉 А лучше всего начните внедрять CSP на свой сайт, сначала в режиме тестирования, а потом в «боевом» виде. На этапе тестирования отчёт поможет вам анализировать какие директивы реагируют на нарушения и соответствующим образом настраивать их.
Полезные материалы по Content Security Policy
Здравствуй дорогой читатель! Я рад приветствовать тебя на страницах моего блога. Уже несколько лет я занимаюсь веб-программированием и рад поделиться с тобой своими знаниями и советами. Если тебе понравились мои статьи, ты можешь подписаться на рассылку блога, из неё ты узнаешь много интересного!
Content Security Policy — опасная политика
Обзор нового веб-стандарта и его фундаментальных уязвимостей
Чтобы идти в ногу со временем, браузеры внедряют все новые технологии для обеспечения безопасности пользователей. Одна из них — Content Security Policy, позволяющая разработчикам сайтов четко объяснить браузеру, на какие адреса тот может выполнять межсайтовые запросы. Однако новый веб-стандарт страдает от существенных недостатков, ставящих под сомнение его пригодность как защиты от XSS.
Content Security Policy vs Same Origin Policy
Одним из главных принципов безопасности браузеров и веба в целом является Same Origin Policy — дословно «политика единого источника» (устоявшегося термина до сих пор не существует). Ее суть заключается в проверке трех компонентов, из которых состоит origin: протокол, хост и порт. Если страница http://test1.ru/a.html пытается получить доступ к DOM страницы http://test2.ru/b.html, то у нее ничего не выйдет, так как хосты отличаются. Если бы SOP не существовал, любой сайт мог бы делать запросы на произвольные адреса и получать оттуда данные, что, как подсказывает логика, не есть хорошо. Причем страдали бы все: как пользователи, чьи персональные данные летали бы без принуждения, так и владельцы ресурсов, — в общем, в вебах творился бы полный хаос. Поэтому Same Origin Policy всех спасает и все счастливы. Однако есть одно но: что, если на страницу http://test1.ru/a.html внедрен злой скрипт с сайта http://test2.ru/, который делает плохие штуки в контексте браузера жертвы? В данном случае SOP бесполезен, ибо на
Очевидно, что такой подход не поможет защититься от случаев, когда у атакующего есть возможность внедрить код в скрипт с валидным токеном. Кроме того, есть масса вариантов обхода, о чем пойдет речь ниже.
CRLF Injection
При наличии CRLF-инъекции в заголовках ответа, то есть отсутствии фильтрации символа переноса строки, у атакующего есть возможность банального обхода CSP с помощью внедрения собственных директив. Здесь большую роль играет то, какой заголовок браузер будет использовать при наличии нескольких с одинаковым именем. Как в случае с HTTP Parameter Pollution, где одинаковые имена параметров обрабатываются по-разному на разных платформах, при внедрении еще одного заголовка Content-Security-Policy важно, где он окажется — перед первоначальным или после него, так как один браузер может взять последний заголовок, а другой — первый. Так, если браузер отдает приоритет первому и мы внедряем наш CSP перед настоящим, то обход тривиален:
Если же используется последний встреченный заголовок, то мы можем отправить его в тело страницы, отправив rnrn:
Таким образом, первоначальный заголовок попадет в содержание HTTP-ответа и не будет иметь силы.
Scriptless Attacks
Перейдем к более интересным вариантам обхода — на стороне клиента. Основная цель межсайтового скриптинга — получить некую приватную информацию пользователя, которая обычно хранится в cookie. Однако с введением таких мер защиты, как флаг httpOnly, запрещающий JS-скриптам доступ к защищаемым cookie, внедрением в браузеры XSS-фильтров (XSS Auditor в Chrome, XSSFilter в IE), собственно и самого CSP, исследователи безопасности все чаще обращают внимание на другие цели, например личные данные, различного рода токены (CSRF, oAuth, в скором будущем и script-nonce). При этом используются новые способы отправки данных на сторонние сайты, без JavaScript!
CSSAR
Еще в 2008 году Эдуардо Вела (Eduardo Vela), Дэвид Линдсей (David Lindsay) и Гарет Хейс (Gareth Heyes) представили технику чтения атрибутов тегов с помощью CSS-селекторов. На данный момент техника все так же актуальна. Если раньше она позиционировалась как обход NoScript, то сейчас ее можно использовать и для CSP. Суть CSSAR (CSS Attribute Reading) в брутфорсе значений с помощью селекторов атрибутов. Для этого на уязвимую страницу подключается CSS-файл с комбинациями выражений:
Если значение целевого инпута начинается с «a», то будет отправлен запрос на сайт атакующего через подгрузку фонового изображения, относящегося к соответствующей комбинации символов. CSS не имеет возможности указать позицию символа, поэтому для получения следующего знака необходимо сгенерировать массу вариантов вида
Поэтому конечный PoC может иметь объем в несколько сотен килобайтов.
CSSAR в действии
Вариант обхода № 4. Postcards from post-XSS world
Интересные идеи предложил Михал Залевски (Michal Zalewski). Например, имея внедрение кода перед формой, защищенной CSRF-токеном, можно вставить незакрытый тег img:
Все содержание страницы до следующей закрывающей кавычки, включая и целевой токен, после незакрытого атрибута src будет отправлено на сайт атакующего.
Настройка Content Security Policy на сайте
Эта информация не нужна обычным пользователям компьютера, но будет полезна для людей, занимающихся разработкой и администрированием сайтов. Как известно страницы сайта состоят из различных ресурсов, таких как скрипты, таблицы стилей, изображения, шрифты и так далее. Они могут загружаться как непосредственно с сервера, где расположен сам сайт, так и с любого другого домена в интернете. Это имеет свои преимущества и недостатки.
Серьезным минусом загрузки ресурсов из другого источника является потенциальная уязвимость внедрения вредоносного контента. Например, в виде межсайтовых скриптовых атак или на английском Cross Site Scripting (XSS) и внедрения зловредных данных. Браузер, загружая страницу доверяет всему контенту, который на ней присутствует, даже если это зловредный код, внедренный незаконно.
Он просто не может отличить один от другого. Как защитить сайт от атак злоумышленников с использованием XSS посвящена данная статья. Для решения подобного рода проблем и повышения безопасности веб-приложений был разработан специальный защитный механизм, подсказывающий браузеру какой контент является незаконным на данной странице.
Content Security Policy (CSP) — это политика безопасности контента устанавливаемая администратором сайта и в декларативной форме с помощью HTTP-заголовка уведомляющая посетителей о доверенных источниках (белых списках) откуда могут быть загружены ресурсы для данной страницы. Это позволяет браузеру клиента блокировать загрузку ресурсов из не доверенных источников, а разработчику получать отчеты о попытках нарушения установленной политики безопасности.
Другими словами, сервер только информирует о перечне доверенных источников и типах ресурсов на данной странице, а исполнение данных рекомендаций лежит полностью на клиентском ПО. Поэтому требуется поддержка данной технологии в браузере, с чем как всегда все не совсем гладко.
На сегодняшний день рекомендацией консорциума W3C является CSP Level 2 которую мы будем рассматривать. Идет работа над Level 3 пока имеющей статус рабочего проекта. Для информирования клиента об использовании политики безопасности контента служит HTTP заголовок Content-Security-Policy который может принимать различные директивы для управления загрузкой ресурсов. Если браузер не поддерживает эту возможность, то он просто игнорируется.
В заголовке перечисляются разрешенные URL для каждого типа контента отдельно. Поэтому даже если злоумышленник сможет внедрить свой код на страницу с домена evil.ru, то он не будет выполнен, если в директиве будет указано использовать только собственный домен.
Правила формирования заголовка
Что такое Content Security Policy мы выяснили, способы добавления на сайт мы рассмотрим позже, а сейчас займемся самим заголовком. Главное правило, которое нужно запомнить. Запрещено все, что не разрешено в директиве в явном виде.
Заголовок должен соответствовать следующему формату. Название заголовка отделяется двоеточием, значения директив (directive) пишутся через пробел, директивы отделяются друг от друга точкой с запятой. Наследование не применяется, каждая директива должна содержать свой «белый список» разрешенных значений.
Имеются специальные ключевые слова, которые записываются в одинарных кавычках.
Директивы Content Security Policy
CSP предоставляет широкий набор директив для разных случаев использования и они являются регистронезависимыми.
default-src — устанавливает значение по умолчанию для других директив, если они не заданы в явном виде. Рассмотрим несколько примеров.
Любые внешние ресурсы могут загружаться только с текущего домена, но запрещены встроенные, динамические, data: и остальные.
Любые ресурсы могут загружаться из любых источников. Не распространяется на встроенные и динамически добавляемые ресурсы.
Дополнительно разрешает инлайн и динамически подключаемые ресурсы.
Устанавливает для всех директив значение по умолчанию «нет», в результате все ресурсы страницы окажутся заблокированными и загрузится только html документ. Рекомендуется использовать, чтобы затем прописать правила только для тех ресурсов, которые реально используются на сайте.
Задает для всех ресурсов необходимость использования HTTPS протокола, все что подключается с использованием обычного HTTP загружено не будет.
script-src — задает разрешенный список источников контента для внешних скриптов JavaScript и других сценариев наподобие таблиц стилей XSLT.
Чтобы это исправить это нужно прямо разрешить свой домен для загрузки JavaScript.
Разрешает загрузку ресурсов из любого источника, но скрипты разрешены только с текущего хоста, site.ru и файл main.js расположенный по адресу example.ru/scripts/main.js
Смысл в том, что сервер каждый раз при запросе страницы генерирует ее заново и подставляет в заголовок Content-Security-Policy, одновременно добавляя в качестве значения атрибута nonce в тег скрипта. Это можно использовать как с внешними, так и со встроенными скриптами.
Браузер сверяет значение из заголовка со значением, указанным в тэге скрипта и если они не совпадают или в скрипте он отсутствует, то такие сценарии блокируются. Поэтому в приведенном далее примере исполнится только второй и четвертый сценарии, хотя домен any.ru в правилах явно не указан. Использование ‘unsafe-inline’ заметно снижает эффективность CSP, поэтому в целях безопасности одноразовое значение должно быть трудно подбираемым. В связи с чем рекомендуется использование криптографически стойкого генератора случайных чисел для его создания.
Альтернативным вариантом для встроенных сценариев является использование их хэша. Он обеспечивает большую надежность, однако сильнее нагружает браузер. Для этого вычисляется хэш кода, расположенного между тегами по алгоритму SHA-256, SHA-384 или SHA-512 и затем кодируется с помощью base64. Получившейся результат добавляется в заголовок с указанием использованного алгоритма хеширования. Так для сценария alert(‘Привет мир!’); это выглядит так.
Браузер вычисляет хэш встроенного сценария на странице и если он совпадает со значением из заголовка, то сценарий выполняется. Стоит помнить, что для хэша имеют значение любые символы, в том числе и пробелы. Поэтому исполнится только первый из следующих вариантов, несмотря на то что сам код идентичен.
Стили могут дополнительно загружаться из папки site.ru/catalog/css и ее подпапок только по защищенному протоколу, все остальное только с собственного домена, так же разрешены встроенные сценарии.
connect-src — адреса с которыми может устанавливаться соединение с помощью интерфейсов JavaScript. Под ее действие попадают XMLHttpRequest, WebSocket, EventSource и подобное.
font-src — регламентирует разрешенные источники загрузки шрифтов. Например, если в директиве default-src задан собственный домен, а ваш сайт загружает веб-шрифты с сервиса google, то необходимо явно разрешить загрузку из внешнего источника.
base-uri — ограничивает URL которые могут использоваться для указания базового адреса в теге документа.
form-action — регламентирует адреса, на которые могут быть отправлены формы на странице.
img-src — список разрешенных источников для загрузки изображений. Изображения, встраиваемые в страницу с помощью data, нужно разрешать отдельно.
Допустимы изображения только с собственного домена, остальное с любого адреса по защищенному протоколу.
Запрещены любые изображения в том числе со своего хоста, но разрешены подключенные через data
media-src — регулирует источники аудио, видео и связанных текстовых данных.
object-src — указывает возможные источники для загрузки плагинов на страницу.
plugin-types — регулирует разрешенный тип встраиваемых плагинов на основе их MIME типа. Например, разрешает только использование Flash.
Если на странице http://site.ru/example будет обнаружено нарушение политики безопасности контента, то на адрес http://site.ru/csp-error будет отправлен отчет о каждой попытке нарушения отдельно. Соответственно по этому адресу должен располагаться скрипт, который будет обрабатывать поступающую информацию. Вид отчета зависит от типа нарушения, это пример для встроенного скрипта.
sandbox — помещает страницу в песочницу и определяет разрешенные действия, используются такие же флаги как и для iframe.
Мы рассмотрели возможности имеющиеся в CSP Level 2 по защите сайта от Cross Site Scripting и подмены контента. Несмотря на очевидные преимущества он не используется в интернете на сегодняшний день достаточно широко. Этому есть простое объяснение. Для его внедрения нужно приложить много усилий и зачастую переписать часть кода для обеспечения надлежащего уровня защиты.
Все относительно просто, когда для загрузки ресурсов используется только собственный домен или несколько заранее известных сторонних адресов. Среднестатистический сайт в интернете использует счетчики посещаемости, различные рекламные сети и виджеты. Все это тянет за собой шлейф из десятков дополнительно загружаемых на страницу ресурсов с самых разных URL зачастую неизвестных заранее.
В этой ситуации настройка становится совсем не тривиальной задачей. Однако даже в этом случае, политика безопасности контента может найти свое применение, например для защиты административной части сайта, страницы оплаты или других важных разделов. Это поможет создать дополнительный барьер от кражи сессий, паролей и другой конфиденциальной информации.
Стоит иметь в виду, что антивирусы могут вмешиваться в работу сайта. Например, Касперский встраивает в страницу собственный скрипт для ее проверки, поэтому когда он обнаруживает в ответе сервера этот заголовок, то он его модернизирует на лету и добавляет правила разрешающие ему выполняться на странице, чтобы браузер его не заблокировал.
Заголовок Content-Security-Policy-Report-Only
Данный заголовок аналогичен предыдущему, с той лишь разницей, что он не блокирует загрузку ресурсов, а только информирует о факте нарушения политики безопасности контента.
Его удобно использовать для отладки политики и сбора статистики. Может применяться на рабочем сайте, так как ничем не выдает свое присутствие для простых посетителей и не создает им проблем. В случае обнаружения нарушений безопасности в консоли будут выводиться соответствующие сообщения, а если указана директива report-uri, то по указанному адресу будет высылаться отчет. При этом нужно учитывать, что при высокой посещаемости сайта поток отчетов может быть высоким.
Как добавить HTML-заголовок на страницу
Здесь все аналогично другим HTTP заголовкам и существует множество вариантов, как это можно сделать. Вот некоторые из них, но помните, что в идеале для каждой страницы сайта должен быть свой набор правил чтобы свести площадь атаки к минимуму.
Сервер Apache, конфигурационный файл httpd.conf
Сервер Nginx, конфигурационный файл nginx.conf
HTML метатег meta добавляется в head страницы. Данный тег не действует на ресурсы, расположенные на странице перед ним. Не может использоваться для Content-Security-Policy-Report-Only
Что делать, если вы не добавляли данный заголовок, но получаете ошибки в консоли связанные с CSP. Значит он добавляется автоматически сервером, CMS или плагином. Нужно найти источник его появления и отключить его вывод или настроить нужным вам образом. Если такой возможно нет, то можно попробовать его переопределить, добавив собственный с нужными настройками.