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

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

Что такое script-src и unsafe-inline?

Директива script-src определяет источники‚ из которых браузеру разрешено загружать JavaScript. Она принимает список источников‚ разделенных пробелами. Источниками могут быть:

  • Домены: Например‚ script-src 'self' https://example.com разрешает загрузку скриптов с текущего домена и с example.com.
  • Ключевые слова: 'self' означает текущий домен‚ 'none' запрещает загрузку любых скриптов.
  • Хэши: Позволяют разрешить выполнение конкретных встроенных скриптов‚ используя их SHA-256 хэш.
  • nonce: Позволяет разрешить выполнение скриптов‚ содержащих определенный случайный токен.

Почему unsafe-inline опасен?

Пример XSS с использованием unsafe-inline:

<input type="text" onmouseover="alert('XSS!')">

Если script-src unsafe-inline разрешен‚ при наведении курсора мыши на этот input-поле выполнится JavaScript-код alert('XSS!'). В реальной атаке злоумышленник может использовать этот код для кражи cookie‚ перенаправления пользователя на вредоносный сайт или изменения содержимого страницы.

Как избавиться от script-src unsafe-inline?

Избавление от unsafe-inline требует пересмотра и рефакторинга JavaScript-кода. Вот несколько шагов‚ которые можно предпринять:

  1. Используйте event listeners: Вместо использования атрибутов HTML-элементов‚ таких как onclick‚ используйте JavaScript для добавления event listeners. Например‚ вместо <button onclick="myFunction"> используйте:

    const button = document.querySelector('button');
button.addEventListener('click'‚ myFunction);
  2. Используйте nonce: Если невозможно полностью избавиться от встроенного JavaScript‚ можно использовать nonce. Nonce – это случайный токен‚ который генерируется на сервере и добавляется к тегу <script>. CSP должна быть настроена на разрешение скриптов с этим nonce. Однако‚ использование nonce требует тщательной реализации‚ чтобы избежать ошибок.
  3. Используйте хэши: Можно использовать хэши SHA-256 для разрешения выполнения конкретных встроенных скриптов. Это более безопасный вариант‚ чем unsafe-inline‚ но требует обновления хэша при каждом изменении скрипта.

Пример CSP без unsafe-inline

Предположим‚ у вас есть JavaScript-код в файле app.js‚ расположенном на том же домене‚ что и ваш сайт. Ваша CSP может выглядеть следующим образом:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' https://fonts.googleapis.com; img-src 'self' data:; font-src 'self' https://fonts.googleapis.com;

Эта CSP разрешает загрузку скриптов только с текущего домена ('self')‚ стилей с текущего домена и Google Fonts‚ изображений с текущего домена и data URI‚ и шрифтов с текущего домена и Google Fonts. unsafe-inline не используется‚ что значительно повышает безопасность вашего сайта.

Инструменты для тестирования CSP

Существует несколько инструментов‚ которые могут помочь вам протестировать и отладить вашу CSP:

  • CSP Evaluator: https://csp-evaluator.withgoogle.com/
  • SecurityHeaders.com: https://securityheaders.com/

Эти инструменты помогут вам выявить ошибки в вашей CSP и убедиться‚ что она правильно настроена.

Использование script-src unsafe-inline значительно ослабляет защиту вашего сайта от XSS-атак. Избавление от unsafe-inline требует усилий‚ но это важный шаг для повышения безопасности вашего веб-приложения; Следуйте рекомендациям‚ описанным в этой статье‚ и используйте инструменты для тестирования‚ чтобы убедиться‚ что ваша CSP настроена правильно и эффективно защищает ваш сайт.