Политика безопасности контента: больше безопасности при использовании веб-контента

Активный контент на сайтах (т.е. JavaScript, CSS, ActiveX) может представлять угрозу безопасности для пользователей Интернета и операторов сайтов, поскольку им можно манипулировать с помощью межсайтовых сценариев. Политика безопасности контента (Content Security Policy, CSP) была введена для того, чтобы обеспечить полноценное использование интернет-сайтов без необходимости беспокоиться о каких-либо рисках безопасности. Стандарт безопасности разработан для защиты от вредоносных атак и в настоящее время поддерживается большинством веб-браузеров. Концепция безопасности защищает как веб-сайты, так и пользователей Интернета. Но что за этим стоит и как работает CSP?

Разработка политики безопасности контента

Политика безопасности контента берет свое начало в 2004 году, когда она еще была известна как «Ограничение контента». Причиной этих усилий стало растущее число уязвимостей в интернет-скриптах. Межсайтовый скриптинг (XSS) — это преступный метод внедрения вредоносного кода на сайт, представляющий серьезный риск для пользователей. Пользователи заходят на надежный сайт, но там запущен скрипт, который загружает вредоносные данные из внешнего источника. Киберпреступники часто используют уязвимости в функциях комментирования веб-сайта. Таким образом, они могут получить доступ к персональным компьютерам без ведома пользователей Интернета. Операторы веб-сайтов даже не заметят, что был внедрен посторонний код.

Чтобы решить эту проблему, Mozilla Foundation способствовала разработке CSP. Преимущество стандарта безопасности заключается в том, что в браузере можно установить правила, указывающие программному обеспечению, какие скрипты ему разрешено загружать, а какие нет. Для этого политика безопасности содержимого использует HTTP-заголовки.

Факт

За разработкой браузера Firefox стоит Mozilla Foundation. Эта некоммерческая организация отвечает за ориентацию проектов и инноваций Mozilla, связанных с интернетом. Фонд был основан бывшими сотрудниками Netscape, которые разработали один из первых веб-браузеров.

Как работает политика безопасности контента?

При общении в Интернете клиенты и сервер обмениваются данными через протокол передачи гипертекста (HTTP). Поля заголовков HTTP являются важной частью запросов и ответов: в них передаются параметры и аргументы, которые важны для обмена информацией между двумя участниками вызова (сервером и клиентом). Они обычно делятся на поля запроса и поля ответа и могут содержать такую информацию, как набор символов, язык и cookies. CSP реализован как поле заголовка ответа. Это означает, что сервер доставляет информацию, а браузер ее обрабатывает.

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

Примечание

Если вы хотите проверить, поддерживает ли ваш браузер политику безопасности содержимого, вы можете использовать тест браузера CSP. Этот тест пытается загрузить скрипты и изображения из неизвестных (безвредных) источников и сообщает вам, удалось ли это сделать.

Что касается политики безопасности содержимого и предотвращения межсайтового скриптинга, операторы веб-сайтов должны хранить все скрипты в отдельных файлах, а не встраивать их непосредственно в исходный код сайта. В этом случае CSP работает аналогично белому списку: в заголовке указываются источники, из которых могут быть загружены скрипты и данные. Если неизвестный скрипт незамеченным проскользнул в HTML-код страницы и теперь пытается загрузить внешние данные, браузер пользователя должен запретить это. По умолчанию CSP блокирует все скрипты, которые можно найти непосредственно в коде (inline scripts). Это защищает как сайт, так и пользователя Интернета, а также любые конфиденциальные данные.

Межсайтовым скриптингом относительно легко манипулировать киберпреступникам. Почти на каждом сайте есть поле ввода, например, функция комментария, строка поиска или поле для входа в систему. Вместо простого текста можно также вводить скрипты. Если сервер не защищен должным образом, преступники могут внедрить фишинговые интерфейсы, заблокировать весь сайт или получить контроль над браузером пользователя с помощью вредоносного программного обеспечения. CSP (а точнее: соответствующее поле заголовка) сообщает веб-браузеру, из каких источников ему разрешено загружать данные. Если политика внедрена в код веб-сайта, то при попытке получить XSS-имплементированный код будет выдано сообщение об ошибке.

Политика безопасности содержимого также позволяет операторам сайта изменять многие другие параметры. Это можно сделать с помощью следующих директив:

  • base-uri: Ограничивает URL, которые могут быть использованы в элементе <base> сайта.
  • child-src: Определяет допустимые источники для веб-рабочих и вложенных контекстов просмотра, загружаемых с помощью таких элементов, как <frame> и <iframe>;
  • connect-src: Ограничивает источники, к которым сайт может подключаться, т.е. ссылки.
  • font-src: Определяет допустимые источники шрифтов
  • form-action: Определяет допустимые источники, которые могут быть использованы в качестве HTML <формы>.
  • frame-ancestors: Определяет допустимые источники для встраивания ресурса с помощью <frame> и <iframes>
  • img-src: Определяет допустимые источники изображений
  • media-src: Определяет допустимые источники аудио и видео
  • object-src: Определяет допустимые источники плагинов
  • plugin-types: Определяет допустимые типы плагинов
  • report-uri: Дает браузеру знать, когда URL (на который отправляются отчеты) нарушает меры безопасности
  • script-src: Определяет допустимые источники JavaScript
  • style-src: Определяет допустимые источники таблиц стилей
  • upgrade-insecure-requests: Определяет, что небезопасные HTTP сайты должны рассматриваться как HTTPS сайты
  • sandbox: Перемещает сайт в «песочницу», где запрещены формы, всплывающие окна и скрипты.

Эти директивы применяются только в том случае, если они явно установлены. В противном случае они открыты по умолчанию и поэтому представляют угрозу безопасности. Однако это можно изменить с помощью default-src: вы можете установить состояние по умолчанию для всех директив, заканчивающихся на -src. Например, вместо того, чтобы оставить их открытыми, вы можете указать, что могут загружаться только данные с вашего собственного сайта, если вы не указали иное в HTTP-заголовке отдельной веб-страницы. В отдельных директивах вы добавляете дополнительные источники.

В поле заголовка можно ввести любое количество директив. Если вы хотите включить несколько директив, разделите их точкой с запятой. Кроме того, вы, как оператор сайта, должны указать все источники в директиве. Многократное включение одной и той же директивы с дополнительными источниками не допускается (как в следующем примере):

script-src example1.local; script-src example2.local

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

script-src example1.local example2.local

Если вам не нужны определенные типы контента для страницы или всего сайта, вы можете ввести в заголовок значение ‘none’ — таким образом вы можете указать, что никакие источники не могут быть загружены вообще. Вы также можете использовать значение ‘self’ — это означает, что браузер может загружать содержимое только из одного источника. Оба значения всегда должны быть заключены в одинарные кавычки, иначе none и self будут интерпретироваться как домены.

Существуют различные варианты заголовков для определения политики безопасности содержимого:

  • Content-Security-Policy
  • X-Webkit-CSP
  • X-Content-Security-Policy .

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

Обычно вы устанавливаете HTTP-заголовки для всего вашего домена. Для подкаталогов вы можете использовать файл .htaccess. Затем вы используете стандарт безопасности CSP, чтобы установить специальные правила для отдельных подстраниц. Например, если вы внедрили кнопку социальных сетей на одной странице, но не на следующей, имеет смысл разрешить доступ к внешнему источнику только на первой странице.

Источники могут быть введены как адреса, по-своему или в виде подстановочных знаков. Таким образом, разрешены следующие записи:

  • script-src example.com:443 — скрипты разрешены только из этого домена через HTTPS
  • script-src ‘none’ — загрузка скриптов запрещена
  • script-src ‘self’ — скрипты могут быть загружены из того же источника, что и текущая страница, но не из поддоменов
  • script-src https: — скрипты могут быть загружены из любого домена, если он начинается с HTTPS
  • script-src example.com — скрипты могут быть загружены из этого домена
  • script-src *.example.com — скрипты из этого домена и всех поддоменов разрешены
  • img-src data: — изображения могут быть загружены через URL-адреса данных

Политика безопасности содержимого в основном предусматривает, что скрипты могут загружаться только из файлов, а не непосредственно из кода сайта. Если вы хотите обойти это, вы можете использовать команду script-src ‘unsafe-inline’. Однако вы должны понимать, что ослабляете безопасность. Стандарт безопасности также запрещает функцию eval (). Эта команда может использоваться для преобразования текста в код JavaScript — но это также может представлять угрозу безопасности. Если вам все еще нужна эта функция, вы можете активировать ее с помощью script-src ‘unsafe-eval’.

Совет

вы можете защитить unsafe-inline с помощью обходного пути. Хеш-значения или источник nonce максимально закрывают эту уязвимость.

Если скриптам больше не разрешено появляться непосредственно в коде, для каждого скрипта необходимо создать отдельный файл. Функция скрипта хранится в файле .js. Код сайта ссылается только на них:

<script src='example.js'></script>

То, что скрипт делает в итоге, описано в файле example.js. Вы также должны хранить элементы стиля в отдельных таблицах стилей. Если вы как оператор веб-сайта хотите внедрить политику интернет-безопасности, недостаточно просто вставить заголовок. Вам также необходимо проверить и настроить исходный код вашего сайта.

Заметка

хотите узнать, насколько безопасен ваш собственный сайт? Mozilla предоставила простой в использовании тест: Observatory by Mozilla сканирует ваш сайт и выставляет оценку после завершения, а также подсказывает, как сделать ваш сайт более безопасным.

Политика безопасности контента: пример

В качестве примера мы покажем вам, как реализовать заголовок Content Security Policy и объясним, чего можно достичь с его помощью.

  • Content-Security-Policy: «default-src ‘none’; script-src ‘self’ *.example.com; style-src ‘self’; img-src ‘self’ data:; font-src ‘self’ fonts.google.com/; report-uri example.org/report.html».
  • X-Content-Security-Policy: «default-src ‘none’; script-src ‘self’ *.example.com; style-src ‘self’; img-src ‘self’ data:; font-src ‘self’ fonts.google.com/; report-uri example.org/report.html»
  • X-WebKit-CSP: «default-src ‘none’; script-src ‘self’ *.example.com; style-src ‘self’; img-src ‘self’ data:; font-src ‘self’ fonts.google.com/; report-uri example.org»

Вы можете видеть, что каждый вариант CSP появляется в заголовке, чтобы можно было обратиться к как можно большему числу различных браузеров. Внутри каждого заголовка содержимое идентично: источники перечисляются друг за другом, а директивы разделяются точкой с запятой. Синтаксис всегда одинаков. Фактически, меняется только название поля, поэтому вы можете легко дублировать содержимое.

Во-первых, мы определяем, что, если иное не указано в директиве, данные не должны загружаться из любого источника (default-src). Это делает работу немного безопаснее. Вы всегда должны сначала определять default-src. Это предотвратит потенциально забытую директиву от пробелов в вашей политике безопасности содержимого.

Далее мы определяем источник, из которого могут быть загружены сценарии (script-src). В примере мы определяем, что браузер загружает сценарии только из одного источника и с сайта example.com, включая все поддомены (вы назначаете подстановочный знак с помощью *). Кроме того, мы определяем, что клиентам разрешено загружать таблицы стилей только из их собственных источников (style-src). Изображения разрешено загружать только из их собственного источника в качестве URL данных (img-src). Согласно заголовку политики безопасности содержимого, шрифты можно загружать только из собственных источников Google. В примере мы указываем место, куда отправляются уведомления, если кто-то пытается нарушить стандарт безопасности (report-uri).

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

Совет

В Интернете можно найти несколько генераторов политики безопасности содержимого. С помощью таких предложений, как CSP Is Awesome или Report URI, вы можете легко и надежно создавать поля заголовков CSP.

Оцените статью
cdelat.ru
Добавить комментарий