Content Security Policy: Защита от script-src

Content Security Policy (CSP) – это мощный механизм безопасности, который позволяет веб-разработчикам контролировать ресурсы, которые браузер может загружать для данной страницы. Это помогает предотвратить различные типы атак, включая Cross-Site Scripting (XSS). В этой статье мы подробно рассмотрим директиву script-src, одну из самых важных частей CSP, и как ее правильно использовать для защиты вашего веб-приложения.

Что такое script-src?

Директива script-src определяет источники, из которых браузеру разрешено загружать JavaScript. По умолчанию, если директива script-src не указана, браузер разрешает выполнение JavaScript из любого источника. Это создает серьезную уязвимость для XSS-атак, поскольку злоумышленник может внедрить вредоносный скрипт на ваш сайт.

script-src позволяет вам указать список разрешенных источников, используя различные ключевые слова и URL-адреса. Это дает вам точный контроль над тем, какие скрипты могут выполняться на вашей странице.

Ключевые слова для script-src

CSP предоставляет несколько ключевых слов, которые можно использовать в директиве script-src:

  • ‘self’: Разрешает выполнение скриптов, расположенных в том же домене, что и сама страница.
  • ‘none’: Запрещает выполнение любых скриптов. Это самый строгий вариант и может быть полезен для страниц, которым JavaScript не нужен.
  • ‘unsafe-eval’: Разрешает использование функций, таких как eval, которые могут динамически генерировать и выполнять JavaScript. Использование ‘unsafe-eval’ также крайне не рекомендуется, так как это создает серьезную уязвимость.
  • ‘strict-dynamic’: Разрешает выполнение скриптов, которые загружены динамически (например, с помощью fetch или XMLHttpRequest) только если они соответствуют политике CSP, которая была применена при первоначальной загрузке страницы.

Примеры использования script-src

Вот несколько примеров того, как можно использовать директиву script-src:

Пример 1: Разрешить скрипты только с текущего домена

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

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

Пример 2: Разрешить скрипты с текущего домена и CDN

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

Этот пример разрешает выполнение скриптов с текущего домена и с CDN по адресу https://cdn.example.com.

Пример 3: Разрешить скрипты с текущего домена, CDN и использовать strict-dynamic

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

Этот пример разрешает выполнение скриптов с текущего домена, CDN и динамически загруженных скриптов, соответствующих первоначальной политике CSP.

Пример 4: Запретить выполнение всех скриптов

Content-Security-Policy: script-src 'none';

Этот пример полностью запрещает выполнение любых скриптов на странице.

Как внедрить CSP

Существует два основных способа внедрения CSP:

  1. HTTP-заголовок: Это наиболее рекомендуемый способ. Вы можете настроить ваш веб-сервер для отправки HTTP-заголовка Content-Security-Policy вместе с ответом на запрос.

Тестирование CSP

Перед внедрением CSP в production-среду важно тщательно протестировать ее, чтобы убедиться, что она не ломает функциональность вашего веб-приложения. Вы можете использовать режим report-only, чтобы отслеживать нарушения политики CSP без фактической блокировки ресурсов. Это позволяет вам выявить и исправить проблемы, прежде чем применять политику в production.

Для использования режима report-only, добавьте директиву report-uri в вашу политику CSP. Браузер будет отправлять отчеты о нарушениях политики на указанный URL-адрес.

Content-Security-Policy-Report-Only: script-src 'self'; report-uri /csp-report-endpoint;

Content Security Policy и, в частности, директива script-src, являются важными инструментами для защиты вашего веб-приложения от XSS-атак. Правильная настройка script-src позволяет вам контролировать источники, из которых браузер может загружать JavaScript, и значительно снизить риск выполнения вредоносного кода. Помните о важности тестирования и избегайте использования небезопасных ключевых слов, таких как ‘unsafe-inline’ и ‘unsafe-eval’.