Использование политики безопасности контента (CSP) для защиты веб-приложений

Перевод статьи: Zbigniew Banach — Using Content Security Policy (CSP) to Secure Web Applications

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

Зачем нам нужен CSP?

Веб-безопасность основана на same-origin policy (SOP), которая запрещает веб-сайту доступ к данным за пределами собственного происхождения. Теоретически этого должно быть достаточно для обеспечения безопасности, но современный интернет требует, чтобы сайты включали множество ресурсов из внешних источников, таких как скрипты и другие ресурсы из сетей доставки контента (CDN), скрипты Google Analytics, шрифты, стили, модули комментариев , кнопки социальных сетей и т.д..

В то же время злоумышленники используют атаки с использованием cross-site scripting (XSS), чтобы обманным путем заставить веб-сайты, которым доверяет пользователь, распространять вредоносный код. Без дополнительных мер безопасности браузер выполнит весь код из доверенного источника и так как он не может определить, какой код является допустимым, то любой внедренный вредоносный код также выполнится.

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

Истории и поддержка браузеров

Content Security Policy — это рекомендация рабочей группы W3C по безопасности веб-приложений. Версия 1 (или уровень 1) была предложена в 2012 году, Level 2  — в 2014 году, а Level 3 разрабатывается с 2015 года в качестве проекта. Хотя это всего лишь рекомендации, создатели браузеров быстро внедрили CSP, начиная с Firefox 4. Подавляющее большинство современных браузеров поддерживают все или почти все директивы уровня 2, и в этой статье описывается уровень 2 CSP как фактический текущий стандарт.

Реализации CSP использовали 3 разных имени заголовка политики безопасности контента, в зависимости от браузера и времени принятия:

• Content-Security-Policy: Стандартное имя заголовка, рекомендованное W3C и используемое всеми современными реализациями (GoogleChrome начиная с версии 25, Firefox начиная с версии 23, Safari и другие браузеры на основе WebKit начиная с версии 528 WebKit). В настоящее время это единственный заголовок для использования.
• X-WebKit-CSP (устарел): Экспериментальный заголовок, используемый в прошлом Chrome и другими браузерами на основе WebKit.
• X-Content-Security-Policy (устарел): Экспериментальный заголовок, используемый в прошлом браузерами на базе Gecko 2.

Использование директив CSP

CSP позволяет определять различные ограничения содержимого с помощью директив, обычно указанных в заголовках ответа HTTP. Вот пример добавления заголовков CSP на веб-сервер Apache:

Header set Content-Security-Policy "default-src 'self';"

Добавленный в файл httpd.conf или .htaccess, он установит политику по умолчанию, разрешающую только контент из текущего источника (подробности см. ниже).

При необходимости вы также можете указать желаемые директивы на уровне страницы, используя метатеги HTML. Вот пример, который устанавливает ту же политику, что и выше:

<meta http-equiv="Content-Security-Policy" content="default-src 
    'self'">

Каждая директива состоит из имени, за которым следует одно или несколько значений, и заканчивается точкой с запятой. Вы можете использовать подстановочный знак * для обобщения целых значений, поддоменов, схем и портов:

Content-Security-Policy: default-src *://*.example.com

Этот заголовок позволяет использовать источники из любого субдомена example.com (но не самого example.com) по любой схеме (http, https и т.д.).

Официальная рекомендация W3C содержит полный список директив с более формальными определениями, но следующий обзор должен дать вам хорошее представление о наиболее часто используемых.

Директивы белого списка источников

Основной целью CSP является ограничение источников веб-контента, поэтому существует множество директив для указания разрешенных источников для различных типов ресурсов. Как только заголовок Content-Security-Policy указан, браузер будет отклонять любой контент из источников, которые явно не занесены в белый список, с использованием любой из приведенных ниже директив. Исходные значения разделены пробелами и могут включать как URL-адреса, так и специальные ключевые слова ‘none’, ‘self’, ‘unsafe-inline’ и ‘unsafe-eval’ (подробно обсуждается ниже). Обратите внимание, что каждая директива может быть указана только один раз в том же заголовке, а ключевые слова должны быть введены в одинарные кавычки.

• default-src является резервной директивой, используемой для определения политики содержимого по умолчанию для большинства исходных директив. Обычно используются default-src ‘self’, чтобы разрешить контент из текущего источника (но не его поддоменов), и default-src ‘none’, чтобы заблокировать все, что явно не занесено в белый список.
• script-src используется для внесения в белый список источников скриптов. Чтобы разрешить скрипты только из текущего источника, используйте script-src ‘self’.
• style-src используется для внесения в белый список источников стилей CSS. Чтобы разрешить таблицы стилей только из текущего источника, используйте style-src ‘self’.
• connect-src указывает разрешенные источники для прямых подключений JavaScript, которые используют объекты EventSource, WebSocket или XMLHttpRequest.
• object-src позволяет контролировать источники плагинов, таких как Flash. Обратите внимание, что вы также можете указать разрешенные типы плагинов, используя директиву plugin-types (не поддерживается в Firefox начиная с v76).
• img-src позволяет ограничить источники изображения.
• font-src указывает разрешенные источники для загрузки шрифтов.
• media-src ограничивает источники для загрузки звуковых и видео ресурсов.
• child-src используется для ограничения разрешенных URL-адресов для worker JavaScript и содержимого встроенных фреймов, включая встроенные видеоролики. На Level 3 вместо этого можно использовать директивы frame-src и worker-src для управления встроенным контентом и рабочими процессами соответственно.
• frame-ancestors ограничивает URL-адреса, которые могут встраивать текущий ресурс в <iframe> , <object> и подобные элементы.

Написание JavaScript и CSS с CSP

Встроенный код является основным вектором нападения, потому что он всегда выполняется в текущем контексте, поэтому его нельзя ограничивать. Когда CSP включен, он блокирует весь встроенный код по умолчанию. Это означает, что никаких встроенных стилей или встроенных сценариев не должно существовать, включая встроенные обработчики событий или javascript: URL поэтому любой новый код должен следовать передовым методам использования исключительно внешних файлов сценариев и стилей. Ключевое слово unsafe-inline разрешает встроенный код для всех или некоторых источников скриптов, но W3C рекомендует избегать его, где это возможно.

Например, страница HTML и JavaScript старого стиля может содержать код сценария как в тегах <script> , так и в обработчиках встроенных событий:

<script>function performButtonAction() {
   alert('You clicked the button!');}
</script>
<button >

<!-- buttonexample.html -->
<script src='buttonexample.js'></script>
<button id='examplebutton'>Want to click the button?</button>

// buttonexample.js
function performButtonAction() {
   alert('You clicked the button!');
}
document.addEventListener('DOMContentLoaded', function () {
   document.getElementById('examplebutton')
      .addEventListener('click', performButtonAction);
});

<script nonce="uG2bsk6JIH923nsvp01n24KE">
   alert('Hello from Netsparker');
</script>

Content-Security-Policy: script-src 'nonce-uG2bsk6JIH923nsvp01n24KE'

<script>alert('Hello from Netsparker');</script>

Content-Security-Policy: script-src 'sha256-db9763638d4e260082532ed81baf740fe3589b0920ce6039233435abfdbc9ef7'

Content-Security-Policy-Report-Only: default-src 'self'; ...; 
    report-uri /your_csp_report_parser;

{
  "csp-report": {
    "document-uri": "http://netsparker.com/index.html",
    "referrer": "http://nasty.example.com/",
    "blocked-uri": "http://nasty.example.com/nasty.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; 
        report-uri http://netsparker.com/your_csp_report_parser"
  }
}