Как настроить content security policy

Content Security Policy как настроить для WordPress да и везде

Что такое Content Security Policy

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

Иногда такой гадости не происходит, а плагин просто подменяет своим кодом рекламу на сайте. Банально вырезает ваш Adsense и ставит свой. Такого юзер вообще не замечает, владелец сайта может почувствовать некоторое падение дохода.

Хуже всего ситуация когда ваши посетители активно используют такие плагины, которые заменяют вашу белую рекламу рекламой чего-то не приличного. Технически это может выглядеть так что пользователь кликая по такой рекламе переходит на неё именно с вашего сайта. Мало того что вы теряете доход, теряете в иммидже ( ваш посетитель ведь не понимает что вы не виноваты, думает что именно владелец сайта завесил весь сайт порно ), но иногда поисковые системы могут понизить вас выдаче за такие переходы с вашего сайта. Поищите такие истории на серче. И, хотя Я уже объявил, что за такие переходы пессимизировать не будет, но вы же понимаете — лучше обезопасить себя. Сделать это возможно как раз с помощью Content Security Policy

Также подмена контента на странице может осуществляется из-за вирусов, троянов, стороннего программного обеспечения, виджетов на сайте и т.д.

Рекомендую почитать ветку на серче , там масса ценной информации, не пожалейте времени прочтите её всю. И пользуясь случаем спасибо все её активным участникам. Особенно Ladycharm ( вообще на посты этого человека на серче стоит обращать внимание, часто очень ценные вещи пишет ), ctit, samimages ( за код для репортов ).

Ещё полезная ссылка на статью 2013 года в блоге Яндекса на Хабре. Там есть упоминания про утилиты для тестирования политик CSP, я их не пробовал, но возможно они вам пригодятся.

Как определить что вам нужно включить Content Security Policy

Проверьте в любой установленной у вас метрике наличие переходов с вашего сайта на сайты на которые переходов быть по определению не должно. Очень хорошо необходимость настройки Content Security Policy видно в метрике Live Internet. В Яндекс Метрике это не так очевидно ( что странно ).

Открываете статистику LI. Пункт переходы на сайты. Если вы видите здесь значительное количество переходов на совершенно левые сайты, то вам стоит задуматься о настройке CSP

Какие риски при неправильной настройке CSP

CSP запрещает сторонним скриптам менять содержимое страницы. Буквально вставлять код, картинки и прочее. Большинство современных сайтов используют у себя на сайте контекстную рекламу, счетчики, виджеты социальных кнопок, виджеты соцсетей, кнопки метрик, сторонние системы комментирования и многое другое. Если вы не правильно настроите Content Security Policy что-то из этого может перестать работать совсем или станет работать не так как ожидалось. Отловить некоторые баги порой очень сложно и не очевидно.

Также, в теории, может упасть или увеличиться, доход с контекстных сетей. Лично у меня он вообще не изменился. Но отзывы есть и о падении и о росте. По логике вещей он должен бы был расти. Ведь первое что делают плагины — это подменяют нашу рекламу.

В итоге если вы не уверены, что делаете, если левого трафика не много, возможно вообще не стоит всем этим заниматься.

Обратите внимание, то что делал я — хорошо работает в моем случае, как будет работать у вас я не знаю. Тут часто многое индивидуально. Я гарантий никаких не даю и ничего не обещаю. Вы всё делаете на свой страх и риск, ко мне без претензий.

Итак как настроить Content Security Policy

Суть настройки Content Security Policy это отправка браузеру посетителя необходимых http заголовков. Если браузер поддерживает эти заголовки, то он будет действовать в соответствии с политиками которые вы пропишите в этом заголовке. Сделать это можно различными способами.

В принципе CSP можно реализовать в виде плагина для WordPress ( более того какие то плагины уже опубликованы в репозитории ). Или просто в functions.php темы отдавать нужные заголовки на экшен send_headers . В некоторых случаях вариант через php единственно возможный ( если нет mod_headers например, или сервер живет под Nginx, к настройкам которого вас не подпустят ). В этой статье про способ на php речи не идет. Если кому-то будет нужно допишу.

Можно вообще описать заголовок Content-Security-Policy в meta вашей темы, но у этого способа есть серьезные ограничения. Этот способ настройки CSP я бы очень не рекомендовал.

Мой случай это WordPress под апачем. Nginx есть, но настроен только для отдачи статики, поэтому все манипуляции делаю в .htaccess в корне сайта. Итак у нас есть апач и доступ к файлу .htaccess в корне вашего сайта. Чтобы отправить заголовки кодом в .htaccess вам нужен модуль апача mod_headers. Проверить его наличие легко, пишем такой код в самое начало .htaccess.

Источник

Ogarkov.com

Зачем?

Настройка Content Security Policy для сайта — не мелочь, а необходимость. Мы не можем знать, что на той стороне у клиента, а это вполне может быть зараженный браузер, зараженные плагины и, в общем, что угодно. Выглядеть это может так: клиент открывает сайт, а вместо ваших рекламных блоков там чужие. Или клиент хочет куда-то нажать, но подгруженный кликандер злоумышленника перехватывает клик и отправляет клиента на левый сайт (возможно, вы найдете переходы на такие сайты в своей статистике LiveInternet).

Content Security Policy защищает пользователя от подобных атак, в явном виде указывая браузеру, откуда разрешено загружать тот или иной контент. Уже два года назад более половины используемых браузеров поддерживали CSP. Сейчас доля поддержки CSP 1.0 приближается к 90% (см. статистику тут ).

Как настроить?

Главное при настройке CSP — это определить список всех доменов и типов контента, которые сайту дозволено загружать с этих доменов (включая всевозможные сторонние скрипты, кнопочки, виджеты, счетчики). Учитывается также протокол: http и https — разные вещи.

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

Более удобный вариант — это расширение для Chrome CSP Tester (спасибо за него кому-то из Яндекс.Почты). При всей своей невзрачности это прекрасный инструмент — за пять минут вы одновременно составляете политику и разбираетесь в том, как она пишется. Все тестируется у себя в браузере. Пока политика не отлажена, на живой сайт ее ставить не нужно.

Краткая инструкция есть на ГитХабе. Суть: ставим расширение, указываем адрес сайта в виде *://*.mydomain.com/* и начинаем с единственной галочки default-src: self. Включаем расширение (галочка Active), загружаем сайт и смотрим ошибки в консоли разработчика. Если, например, какой-то контент хочет загрузиться во фрейме, а политика не дает, в тексте ошибки будет ссылка на это (frame-src в данном случае — значит, туда нужно добавить адрес источника). После каждого изменения политики не забываем сохраняться.

Адреса перечисляются через пробел, обычно в следующем виде:

• ‘self’ — текущий домен, протокол и порт;
• *.site.com — все поддомены;
• site.com — домен (во «все поддомены» он не входит);
• https://*.site.com или https://site.com — аналогично для https.

Для выполнения скриптов, возможно, потребуется добавить ‘unsafe-inline’ и/или ‘unsafe-eval’ (подробнее см. в других источниках, это может быть небезопасно).

Если изображения загружаются из разных источников, в image-src для простоты можно поставить звездочку.

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

Как включить на сайте?

Переключив CSP Tester в Advanced mode, можно увидеть составленную политику в виде текстовой строки. Теперь ее можно добавить в .htaccess:

Отключаем расширение, загружаем сайт, убеждаемся, что заголовок Content-Security-Policy приходит и еще раз проверяем, нет ли ошибок в консоли.

Источник

Content Security Policy (CSP)

Content Security Policy (CSP) — это дополнительный уровень безопасности, позволяющий распознавать и устранять определённые типы атак, таких как Cross Site Scripting (XSS (en-US) ) и атаки внедрения данных. Спектр применения этих атак включает, но не ограничивается кражей данных, подменой страниц и распространением зловредного ПО.

CSP разрабатывался с возможностью полной обратной совместимости (за исключением CSP version 2, в которой были намеренно определены некоторые противоречия блокирующие обратную совместимость; с деталями можно ознакомиться здесь, в пункте 1.1). Браузеры, которые не поддерживают CSP, все ещё могут работать с серверами, которые поддерживают CSP, и наоборот: браузеры, в которых поддержка CSP отсутствует, будут её игнорировать, продолжая работу в соответствии со стандартными правилами ограничения домена для загрузки контента. В случае, если сайт не предоставляет CSP-заголовки, браузеры, в свою очередь, будут использовать стандартные правила ограничения домена.

Для того чтобы включить CSP, необходимо настроить сервер так, чтобы в ответах он использовал HTTP-заголовок Content-Security-Policy (en-US) (в различных примерах и документации можно встретить вариант заголовка X-Content-Security-Policy . Он является устаревшим и определять его не нужно).

В качестве альтернативы настройке сервера, вы можете сконфигурировать 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-заголовка и указания какую политику использовать:

Где policy — это строка, содержащая директивы, описывающие вашу Content Security Policy.

Создание политики

Политика описывается с помощью специальных директив, каждая из которых отвечает за отдельный вид ресурсов или policy area. Политика обязательно должна содержать директиву default-src (en-US), которая будет использоваться для тех ресурсов, для которых не будет описано отдельных правил (полный список вы можете найти в описании директивы default-src (en-US)). Для того чтобы предотвратить исполнение встраиваемых скриптов и заблокировать использование eval() , необходимо определить директиву default-src (en-US) или script-src (en-US). Также использование директивы default-src (en-US) или style-src (en-US) позволит ограничить использование встраиваемых стилей как в style -атрибутах, так и в тэгах .

Примеры: Распространённые случаи применения

В данном разделе приводятся наиболее распространённые сценарии использования CSP.

Пример 1

Вы хотите ограничить источники контента только исходным сервером (исключая поддомены)

Пример 2

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

Пример 3

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

При такой настройке, весь контент доступен для получения только с исходного домена, со следующими исключениями:

• Изображения могут быть получены из любого источника (источник — «*»).
• Другие медиа-файлы доступны только с media1.com и media2.com (но не с их поддоменов).
• Исполняемый код доступен только с userscripts.example.com.

Пример 4

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

При данной настройке сервер будет позволять загрузку страниц только по HTTPS и только из одного источника — onlinebanking.jumbobank.com.

Пример 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) следующим образом:

В случае, если оба заголовка (Content-Security-Policy-Report-Only (en-US) и Content-Security-Policy (en-US)) были определены одновременно в одном ответе сервера, обе политики будут обработаны. Политики, описанные в заголовке Content-Security-Policy будут применены, в то время как политики, описанные в заголовке Content-Security-Policy-Report-Only , создадут отчёты, но применены не будут.

Настройка отправки отчётов

По умолчанию, отправка отчётов не производится. Для того чтобы включить отправку отчётов, необходимо в вашей политике определить директиву report-uri (en-US) и указать как минимум один URI, куда будут направляться отчёты:

Кроме того, необходимо настроить свой сервер на получение этих отчётов; вы можете хранить и обрабатывать эти отчёты как считаете нужным.

Синтаксис отчёта о происшествиях

Объект отчёта в формате JSON содержит следующие поля:

blocked-uri URI ресурса, заблокированного в соответствии с настройками политики. Если заблокированный адрес отличается от адреса страницы, то он будет сокращён до схемы, хоста и порта. disposition Принимает значения «enforce» или «reporting» в зависимости от того, какой заголовок используется Content-Security-Policy-Report-Only (en-US) или Content-Security-Policy . document-uri URI страницы, на которой произошло нарушение. effective-directive Директива, исполнение которой привело к нарушению. original-policy Исходная политика, описываемая в заголовке Content-Security-Policy . referrer Реферер, который привёл к нарушению. script-sample Первые 40 символов встроенного скрипта или стиля, спровоцировавшего нарушение. status-code The HTTP status code of the resource on which the global object was instantiated. violated-directive Директива, которая была нарушена.

Пример отчёта о происшествии

Как видите, отчёт включает полный путь к ресурсу нарушающему политику в blocked-uri . Правда, это не всегда так. К примеру, когда signup.html попытается загрузить CSS с http://anothercdn.example.com/stylesheet.css , браузер не будет включать полный путь, а ограничится лишь доменом ( http://anothercdn.example.com ). Спецификация CSP поясняет это странное поведение. В целом, это делается для предотвращения утечек чувствительной информации о перекрёстных ресурсах

Совместимость с браузерами

BCD tables only load in the browser

Для некоторых версий Safari существует специфическая несовместимость реализации CSP. Если установить заголовок Content Security Policy без заголовка Same Origin, то браузер начнёт блокировать и создавать ложно-положительные отчёты о нарушении политики для всего контента, как с запрашиваемого источника, так и из внешних источников.

Источник