Открыть сервис
Главная → Блог → Content Security Policy

Content Security Policy

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

История и развитие

Идея создания механизма, позволяющего веб-приложениям контролировать загружаемые ресурсы, возникла в середине 2000-х годов в ответ на рост числа атак, связанных с XSS. Первоначально концепция была предложена Адамом Бартом (Adam Barth) и другими исследователями из Google. В 2009 году вышла первая черновая версия спецификации CSP 1.0.

В 2012 году спецификация CSP 1.0 была опубликована W3C (World Wide Web Consortium) в качестве кандидата в рекомендации. В 2015 году была выпущена версия CSP 2.0, которая добавила поддержку для <base>-элементов, form-action и других директив. В 2018 году была опубликована версия CSP 3.0, которая находится в стадии разработки и включает в себя такие нововведения, как strict-dynamic, 'unsafe-hashes' и улучшенную поддержку для Web Workers.

Принцип работы

CSP работает на основе политики, которая передаётся от сервера к браузеру через HTTP-заголовок Content-Security-Policy или через мета-тег <meta (организация признана экстремистской, деятельность запрещена в РФ) http-equiv="Content-Security-Policy" content="..."> в HTML-документе. Политика представляет собой набор директив, каждая из которых определяет правила для определённого типа ресурса.

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

Основные директивы

  • default-src: Устанавливает политику по умолчанию для всех типов ресурсов, для которых не указаны отдельные директивы.
  • script-src: Определяет разрешённые источники для JavaScript-скриптов.
  • style-src: Определяет разрешённые источники для CSS-стилей.
  • img-src: Определяет разрешённые источники для изображений.
  • font-src: Определяет разрешённые источники для шрифтов.
  • connect-src: Определяет разрешённые источники для сетевых запросов (например, fetch, XMLHttpRequest).
  • frame-src: Определяет разрешённые источники для встраиваемых фреймов (<iframe>).
  • report-uri / report-to: Указывает URL, на который браузер отправляет отчёты о нарушениях политики.

Источники

Директивы CSP могут содержать следующие значения, определяющие разрешённые источники:

  • 'self': Разрешает ресурсы с того же источника (домен, протокол, порт), что и страница.
  • 'none': Запрещает все ресурсы данного типа.
  • 'unsafe-inline': Разрешает встроенные скрипты и стили (например, <script>alert(1)</script> или style="..."). Использование этой директивы значительно снижает защиту от XSS.
  • 'unsafe-eval': Разрешает использование функций eval(), setTimeout() со строковым аргументом и других динамических методов выполнения кода. Также снижает безопасность.
  • 'strict-dynamic': В версии CSP 3.0 позволяет скриптам, загруженным из доверенного источника, динамически загружать другие скрипты. Это упрощает управление политиками для сложных приложений.
  • 'nonce-<base64-значение>': Разрешает выполнение только тех встроенных скриптов, которые содержат атрибут nonce с указанным значением. Значение nonce должно генерироваться на сервере для каждого запроса.
  • 'hash-<алгоритм>-<base64-значение>': Разрешает выполнение встроенных скриптов, хеш которых (SHA-256, SHA-384 или SHA-512) совпадает с указанным.
  • <домен>: Разрешает ресурсы с указанного домена (например, https://example.com`).
  • <схема>: Разрешает ресурсы по указанной схеме (например, https: или data:).

Применение

CSP широко используется для защиты веб-приложений от различных типов атак:

  • Защита от межсайтового скриптинга (XSS): CSP блокирует выполнение скриптов, внедрённых злоумышленником, если они не соответствуют политике. Это наиболее эффективный способ предотвращения XSS-атак на уровне браузера.
  • Защита от кликджекинга: Директива frame-ancestors (в CSP 2.0) позволяет запретить встраивание страницы в <iframe> на других сайтах, предотвращая атаки типа «перехват клика».
  • Защита от утечки данных: Директива connect-src может ограничить отправку данных на сторонние серверы, что затрудняет кражу информации.
  • Снижение риска от инъекций контента: CSP ограничивает типы контента, которые могут быть загружены, что уменьшает вероятность успешных атак, связанных с загрузкой вредоносных файлов.

Примеры политик

  1. Базовая политика, разрешающая только собственный контент:

Content-Security-Policy: default-src 'self';

  1. Политика, разрешающая скрипты только с собственного сервера и с доверенной CDN, а также встроенные скрипты с nonce:

Content-Security-Policy: script-src 'self' https://cdn.example.com 'nonce-abc123';

  1. Политика, запрещающая встроенные скрипты и eval, но разрешающая изображения из любого источника:

Content-Security-Policy: default-src 'self'; script-src 'self'; img-src *;

  1. Политика с отчётами о нарушениях:

Content-Security-Policy: default-src 'self'; report-uri /csp-violation-endpoint;

Критика и ограничения

  • Сложность настройки: Для крупных и сложных веб-приложений, особенно использующих множество сторонних библиотек, настройка CSP может быть трудоёмкой. Неправильно настроенная политика может блокировать легитимный функционал.
  • Необходимость поддержки со стороны браузера: Хотя современные браузеры поддерживают CSP, устаревшие версии могут игнорировать политику, что снижает эффективность защиты.
  • Не является панацеей: CSP не защищает от всех видов атак, таких как SQL-инъекции, CSRF (межсайтовая подделка запроса) или атаки на серверную часть. Он является лишь одним из слоёв защиты.
  • Проблемы с производительностью: Генерация и проверка nonce для каждого запроса может незначительно увеличить нагрузку на сервер.
  • Возможность обхода: При использовании 'unsafe-inline' или 'unsafe-eval' защита CSP значительно ослабляется, и атаки XSS могут быть успешными.

Интересные факты

  • CSP является частью более широкой концепции «безопасности на основе политик» (Policy-Based Security), которая также включает в себя такие механизмы, как HTTP Strict Transport Security (HSTS) и X-Content-Type-Options.
  • В CSP 3.0 появилась возможность использования 'report-to' вместо 'report-uri', что позволяет отправлять отчёты в структурированном формате JSON.
  • Некоторые браузеры, включая Google Chrome, поддерживают экспериментальный режим «CSP в режиме отчёта», который позволяет тестировать политику без её фактического применения, только собирая отчёты о нарушениях.
  • CSP может быть использован для защиты от атак, связанных с использованием уязвимостей в браузерах, таких как Spectre и Meltdown, путём ограничения доступа к чувствительным данным.

Источники

  1. W3C Candidate Recommendation. Content Security Policy Level 2. 2015.
  2. W3C Working Draft. Content Security Policy Level 3. 2023.
  3. OWASP. Content Security Policy Cheat Sheet.
  4. Mozilla Developer Network (MDN). Content Security Policy (CSP).
  5. Google Developers. An Introduction to Content Security Policy.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы