О политике защиты контента: что это, зачем это нужно, и как обеспечить защиту данных вашего сайта, если вы никогда не занимались этим раньше.
Интернет основан на политике «одного источника». Только код mysite.com имеет доступ к данным cookie, хранилищу, ajax-запросам mysite-а. Он полностью изолирован от других доменов.
К несчастью, не все так просто. Современные сайты состоят из многих частей и подгружают набор сторонних компонентов, стилей и скриптов. Скрипт, загруженный с другого домена, запускается в контексте текущей страницы и может делать все, что вздумается его автору. Так кнопка социальной сети может отслеживать посетителей, перехватывать учетные данные, менять контент страницы и многое другое. Даже если вы доверяете стороннему сайту, вы можете стать жертвой атаки посредника, когда скрипт претерпевает изменения прежде чем дойти до вас.
К счастью, возможно наложить определенные ограничения, используя CSP (политику защиты контента), которая предотвращает непредвиденные угрозы безопасности. CSP определяет, что разрешено и запрещено браузеру. Например, можно запускать скрипты на mysite.com, но только из файлов, а не встроенных тегов <script>.
Тестируйте свой сайт
Чтобы проверить, реализуется ли CSP на вашем сайте, зайдите на observatory.mozilla.org, введите адрес и нажмите Scan Me. Веб-сайты, не имеющие контентной защиты, будут оценены на F.
Политика защиты контента необходима для банков, интернет-магазинов, социальных сетей и любых сайтов, где предусмотрены пользовательские аккаунты. Защита не так принципиальна, если ваш сайт не использует сторонние скрипты, шрифты, медиа, виджеты и инструменты аналитики. Но можно ли быть в этом уверенным?
Внедрение политики защиты контента
Политика безопасности контента должна быть внедрена на каждую страницу сайта разработчиком или хостером. Она определяется с использованием HTTP-заголовка Content-Security-Policy на серверном языке (PHP, Node.js, Ruby и т. д.) или в конфигурационном файле сервера.
# Применить CSP ко всем HTML и PHP файлам <FilesMatch "\.(html|php)$"> Header set Content-Security-Policy "policy-definition"
Позже мы скажем несколько слов о значении «policy-definition».
Серверные конфиги практичны, поскольку они применяют один хедер ко всем страницам, расположенным ниже в файловой иерархии. Однако можно задать политику безопасности и в <head> HTML-файла используя тег meta:
<meta http-equiv="Content-Security-Policy" content="policy-definition">
Это может пригодиться, если вы не обладаете правами на конфигурацию сервера, либо если для разных страниц требуется разная политика безопасности.
Определение политики защиты контента
Переходим к сложной части. CSP определяют «белый список» допустимых доменов и контекстов для различных типов контента.
Предположим, вы хотите разрешить выполнение только скриптов с вашего домена. Тогда вам нужно использовать следующее объявление:
script-src 'self';
Затем вы вспоминаете, что вместе с этим подгружаете стороннюю библиотеку с CDN, которая может появляться на некоторых поддоменах вашего домена. Тогда маска субдомена добавляется в список:
script-src 'self' *.mycdn.com;
Следом вы осознаете, что на страницах запускаются встроенные скрипты:
script-src 'self' *.mycdn.com 'unsafe-inline';
Итак, мы установили политику для скриптов. Но мы не сказали ни слова о стилях, медиа, шрифтах и т. п., поэтому все это просто не загрузится. Исправим это упущение с помощью default-src:
default-src 'self'; script-src 'self' *.mycdn.com 'unsafe-inline';
Отметим, что объявления типов контента разделены точкой с запятой (;).
Теперь мы можем использовать нашу политику в конфиге сервера:
Header set Content-Security-Policy "default-src 'self'; script-src 'self' *.mycdn.com 'unsafe-inline';"
...или в мета теге страницы:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' *.mycdn.com 'unsafe-inline';">
Рекомендации по политике защиты контента
Практичнее всего начинать со строгой политики по умолчанию default-src 'none'; и затем по мере необходимости добавлять дополнительные разрешения. Хорошей отправной точной для большинства сайтов будет:
default-src 'none'; style-src 'self' data:; img-src 'self' data:; script-src 'self'; connect-src 'self';
Это разрешает скрипты, стили, изображения и ajax-запросы из того же источника.
Откройте свою страницу в браузере и запустите консоль разработчика. О заблокированных ресурсах будет выведено сообщение вида:
Refused to load the script 'XXX' because it violates the following Content Security Policy directive: "YYY".
Возможно, вам придется просмотреть несколько страниц, чтобы убедиться, что у вас загружаются все необходимые шрифты, изображения, видео, скрипты и плагины.
Сервисы Google
Google предлагает широкий спектр сервисов, и вы наверняка пользуетесь их аналитикой, шрифтами или картами. К сожалению, они разрешены на многих сайтах, требующих дальнейших ajax-запросов, встроенных вызовов и др. Вы можете покончить с такой сомнительной политикой следующим образом:
default-src 'self'; style-src 'self' 'unsafe-inline' *.googleapis.com; script-src 'self' *.google-analytics.com *.googleapis.com data:; connect-src 'self' *.google-analytics.com *.googleapis.com *.gstatic.com data:; font-src 'self' *.gstatic.com data:; img-src * data:;
(Разрывы строк были добавлены для удобства восприятия, в реальном коде они не используются).
Тестируйте снова
Наконец, протестируйте ваши страницы на observatory.mozilla.org еще раз. Скорее всего, оценка политики защиты заметно улучшится.
Комментарии