Эта статья является частью серии, созданной в сотрудничестве с SiteGround . Спасибо за поддержку партнеров, которые делают возможным использование SitePoint.
Сеть основана на политике «того же происхождения». Только код на mysite.com может получить доступ к данным mysite.com в файлах cookie, localStorage, Ajax-запросах и т. Д. Он изолирован от других доменов, поэтому любые попытки доступа с evilsite.com будут отклонены.
К сожалению, это никогда не было так просто. Современные веб-сайты являются сложными и загружают различные сторонние компоненты, стили и сценарии. Сценарий, загруженный из другого домена, выполняется в контексте текущей страницы и может делать все, что угодно. Эта кнопка в социальной сети может отслеживать посетителей, захватывать файлы cookie для входа, изменять содержимое страницы и многое другое. Даже если вы доверяете стороннему сайту, вы можете стать жертвой атаки «человек посередине», когда сценарий изменяется до того, как он достигнет вас. Кроме того, это может позволить пользователям запускать свои собственные атаки межсайтового скриптинга (XXS) .
По умолчанию браузеры реализуют подход « все идет» . К счастью, можно применить ограничения, используя Политику безопасности контента (CSP), которая предотвращает непредвиденные проблемы безопасности. CSP сообщает браузеру, что разрешено, например, запускать JavaScript на mysite.com, но только из файлов, а не встроенных тегов <script> .
Протестируйте свой сайт
Чтобы проверить, реализован ли CSP на вашем сайте, посетите observatory.mozilla.org , введите URL-адрес страницы и нажмите « Сканировать меня» . Те, у кого нет защиты CSP, скорее всего, получат F (хотя проводятся и другие проверки).
CSP следует считать важным для банков, интернет-магазинов, социальных сетей и любого сайта, на котором реализованы учетные записи пользователей. Это менее необходимо, если ваш сайт не использует сторонние скрипты, шрифты, мультимедиа, виджеты или аналитику, но можете ли вы быть уверены, что никогда не будет?
Реализация политики безопасности контента
Политика безопасности контента должна быть добавлена на каждую страницу вашим разработчиком или веб-хостингом. Он определяется с помощью HTTP-заголовка Content-Security-Policy, установленного на серверном языке (PHP, Node.js, Ruby и т. Д.), Или в конфигурации сервера, такой как файл Apache .htaccess , например
# Apply a CSP to all HTML and PHP files <FilesMatch "\.(html|php)$"> Header set Content-Security-Policy "policy-definition" </FilesMatch>
(Мы скоро обсудим значение «определения политики».)
Файлы конфигурации сервера являются практичными, поскольку они применяют один и тот же заголовок ко всем страницам в иерархии подпапок. Однако вы также можете определить политику в HTML <head> любой страницы, используя meta :
<meta http-equiv="Content-Security-Policy" content="policy-definition">
Это может быть необходимо, если у вас нет разрешения на настройку сервера или требуются разные политики на каждой странице.
Определение политики безопасности контента
Теперь о сложной части. CSP определяют белый список разрешенных доменов и контекстов для различных типов контента.
Предположим, вы хотите разрешить только скрипты, загруженные с вашего домена. Вы можете использовать следующий CSP (пожалуйста, пока не делайте этого по-настоящему — это всего лишь пример!) :
script-src 'self';
Затем вы понимаете, что загружаете стороннюю библиотеку из CDN, которая может появляться в различных поддоменах mycdn.com . Подстановочный знак домена добавляется в разделенный пробелами список:
script-src 'self' *.mycdn.com;
Затем вы вспоминаете, как некоторые из ваших скриптов запускаются на странице, и мы можем определить это тоже:
script-src 'self' *.mycdn.com 'unsafe-inline';
Теперь у нас есть политика для скриптов. Однако мы не определили другие типы, поэтому все таблицы стилей, изображения, шрифты и т. Д. Не будут загружаться. Чтобы решить эту проблему, мы можем применить политику по default-src используя default-src который служит запасным вариантом для любого неопределенного типа:
default-src 'self'; script-src 'self' *.mycdn.com 'unsafe-inline';
Обратите внимание, что каждое определение типа содержимого разделяется точкой с запятой (;). Теперь мы можем использовать эту политику в нашем файле .htaccess :
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';">
Справочник CSP
Полный набор директив CSP:
| директива | описание |
|---|---|
default-src |
резервная политика по умолчанию. Обычно устанавливается в 'self' или 'none' чтобы гарантировать, что все остальные директивы должны быть объявлены |
style-src |
действительные источники стилей |
script-src |
действительные источники JavaScript |
connect-src |
допустимые источники Ajax, WebSocket или EventSource для поиска данных JavaScript |
form-action |
действительные источники для атрибутов действия form |
img-src |
действительные источники изображений |
font-src |
действительные источники шрифтов |
media-src |
действительные источники audio и video элементов HTML5 |
object-src |
допустимые источники плагинов для HTML- object , элементов embed и applet |
plugin-types |
допустимые типы MIME для плагинов, вызываемых object и embed , например application/pdf |
frame-src |
допустимые источники frame и iframe (теперь не рекомендуется использовать вместо этого child-src ) |
child-src |
действительные источники frame и frame |
frame-ancestors |
допустимые источники встраивания для элементов frame , iframe , object , embed и applet |
sandbox |
включает песочницу для ресурса аналогично атрибуту песочницы HTML5 iframe . Это имеет ряд ограничений, уникальных для этой директивы: allow-forms , allow-same-origin , allow-scripts , allow-popups , allow-modals , allow-orientation-lock , allow-pointer-lock , allow-presentation , allow-popups-to-escape-sandbox и allow-top-navigation |
report-uri |
адрес, по которому браузер может отправлять POST отчеты о сбоях политик |
Справочник Источников CSP
Исходные директивы CSP, заканчивающиеся на -src поддерживают следующие значения. Можно использовать любое количество разделенных пробелами значений:
| источник | описание |
|---|---|
'none' |
предотвращает загрузку из любого источника, например, frame-ancestors 'none' останавливает страницу, показывающую любой iframe или плагин. Значение не может сопровождаться другими источниками |
'self' |
позволяет загружать из источников одного и того же источника (протокол, домен / IP и порт) |
https: |
разрешены только источники по HTTPS-соединениям |
data: |
разрешает данные: источники, например, style-src data: разрешает изображения в кодировке base64 в ваших таблицах стилей |
* |
подстановочный знак для любого URL |
*.domain.com |
разрешает источники из любого поддомена domain.com, например www.domain.com, cdn.domain.com и т. д. |
exact.domain.com |
разрешает источники с точного |
https://exact.domain.com/ |
разрешает HTTPS-источники в данном домене |
'unsafe-inline' |
разрешает встроенный CSS, скрипты, javascript: URI и обработчики событий элемента, такие как onclick в HTML |
'unsafe-eval' |
разрешает небезопасный динамический код с помощью функции JavaScript eval() |
'nonce- id ' |
разрешает запуск встроенного CSS или скрипта, если id соответствует значению атрибута nonce, например, script-src 'nonce-abc123' запускает встроенный код в блоке <script nonce="abc123">...</script> |
'sha256- hash ' |
разрешает стили или сценарии, если содержимое файла соответствует сгенерированному хеш-значению SHA-256 |
Рекомендации по развитию CSP
Практично начать со строгой политики по 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 предоставляет широкий спектр услуг, и вы, возможно, используете аналитику, шрифты, карты и многое другое. К сожалению, они включены в ряде URI, которые требуют дополнительных вызовов 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, и, если повезет, ваша оценка Политики безопасности контента значительно повысилась. Инструмент также сообщит о старых браузерах, HTTPS, CORS, MIME, файлах cookie, заголовках политики реферера и перенаправления.
Реализация политики безопасности контента является важным шагом в предотвращении непредвиденных проблем безопасности. Другим важным шагом является выбор хостинг-провайдера, который принимает меры безопасности близко к сердцу. Наш партнер SiteGround — отличный вариант для тех, кто ищет платформу веб-хостинга, созданную для обеспечения повышенной безопасности веб-сайтов.