Владельцу веб-сайта полезно знать о проблемах безопасности, которые могут повлиять на ваш сайт. Например, атаки с использованием межсайтовых сценариев (XSS) состоят из внедрения вредоносных сценариев на стороне клиента в веб-сайт и использования веб-сайта в качестве метода распространения.
Вы, вероятно, также знаете, что клиентские сценарии можно запрограммировать практически на что угодно. Они могут быть такими же простыми, как отображение предупреждающего сообщения на вашем веб-сайте, анимация изображений, майнинг криптовалют или отображение всплывающих окон, содержащих фармацевтические продукты NSFW.
Внедрение вредоносных скриптов на уязвимые веб-сайты
Важно понимать, что когда злоумышленники находят веб-сайт, уязвимый для XSS-атак, у них есть два варианта внедрения в него вредоносных скриптов:
- Встроенный скрипт: когда злоумышленники вставляют свой код непосредственно в HTML-код вашего веб-сайта.
- Загрузить скрипт из внешнего домена: когда злоумышленники загружают скрипт с нескольких зараженных сайтов и изменяют его по мере необходимости. Все изменения будут отражены на этих сайтах.
Загрузка скриптов из внешнего домена является предпочтительным методом для злоумышленников.
XSS-атаки
Атаки XSS возможны, потому что браузеры доверяют всем запросам, поступающим с вашего веб-сайта, встроенным или из внешнего источника. Цель этого поста — познакомить вас с инструментом, который может помочь снизить некоторые риски XSS-атак.
Согласно веб-сайту W3, Политика безопасности контента (CSP):
Инструмент, который разработчики могут использовать для блокировки своих приложений различными способами, снижая риск уязвимостей, связанных с внедрением контента, таких как межсайтовые сценарии, и уменьшая привилегии, с которыми выполняются их приложения.
CSP делает это, позволяя веб-разработчикам определять такие директивы, как:
- Выполнять весь код из моего домена (например, awesomedomain.com)
- Выполнять весь код, поступающий из внешнего доверенного домена и поддоменов (например, *.trusteddomain.com)
- Ничего не выполнять, кроме скрипта awesomedomain.com/script.min.js
- Не выполнять JavaScript
- Показывать только изображения с сайта cdn.securecdn.com
- Микс из прошлых примеров и многое, многое другое!
Firefox будет учитывать вторую версию CSP, начиная с версии 31, Chrome, начиная с версии 40, и Safari, начиная с версии 10. Браузеры, которые не поддерживают поддержка его просто проигнорирует.
Определение и предоставление CSP
Каждый CSP состоит из двух частей:
- Первая часть представляет собой набор директив, которые сообщают браузерам посетителей вашего веб-сайта, как управлять определенными ресурсами на вашем веб-сайте.
- Вторая часть — это распоряжение, которое сообщает браузерам, следует ли применять CSP или нет.
Мы поговорим о расположении CSP позже в посте.
Давайте посмотрим на пример того, как мы можем определить политику для JavaScript, используя директиву script-src.
Content-Security-Policy: script-src 'none'
Эта директива предотвратит выполнение JavaScript в браузерах, которые соблюдают политику безопасности контента.
Теперь, когда мы создали одну директиву, давайте на мгновение остановимся и посмотрим, как мы можем доставить ее в браузер посетителей вашего сайта. У вас есть два варианта:
Первый вариант заключается в использовании тега HTML, который следует размещать как можно раньше в HTML-коде ваших веб-страниц.
Вот как можно настроить директиву script-src для блокировки всего JavaScript в теге ‹ meta ›:
<meta http-equiv="Content-Security-Policy" content="script-src 'none';">
Второй метод заключается в использовании заголовка HTTP-ответа Content-Security-Policy.
Например, если вы используете Apache, вы можете определить CSP в файле httpd.conf, VirtualHost или .htaccess вашего сайта.
Просто добавьте это так (тот же пример, блокирующий весь JavaScript):
Header set Content-Security-Policy “script-src 'none';”
Второй способ считается более безопасным и, собственно, сам W3 рекомендует именно так обслуживать CSP.
Примеры политик
Прежде всего, давайте посмотрим на некоторые директивы, которые мы можем определить в наших политиках:
- script-src ограничит место, из которого выполняются скрипты (он также заблокирует встроенные скрипты и функцию eval()).
- media-src будет ограничивать место, из которого загружаются видео, аудио и связанные с ними ресурсы текстовой дорожки.
- frame-src ограничит место, из которого загружаются iFrames.
- img-src ограничит место загрузки изображений.
- font-src ограничит место, из которого загружаются файлы шрифтов.
- style-src ограничит место загрузки файлов .css (а также заблокирует встроенные стили).
- default-src применит политику безопасности к child-src, connect-src, font-src, frame-src, img-src, manifest-src, media-src, media-src, object-src, script-src, style. -src и worker-src, где они сами не определены (сэкономит вам ввод текста!).
Вы можете увидеть полный список директив, которые вы можете установить на сайте W3.
Во-вторых, давайте посмотрим на некоторые из ключевых слов/значений, которые вы можете задать для своих директив:
- «none» не будет соответствовать ничему — это означает, что все элементы, контролируемые директивой, будут заблокированы (см. наш пример с блокировкой всего JavaScript на странице).
- «self» будет соответствовать происхождению текущего URL-адреса (URL-адрес вашего веб-сайта).
- «https://*» будет соответствовать всем ресурсам, загружаемым через HTTPS.
- '*.awesomedomain.net' будет соответствовать домену awesomedomain.net и всем поддоменам
'https://awesomedomain.net/script.js' будет соответствовать только скрипту script.js в домене awesomedomain.net через HTTPS. .
Давайте теперь посмотрим на несколько конкретных примеров.
Пример 1:
CSP Разрешение только JavaScript, размещенного на вашем сайте
Content-Security-Policy: script-src 'self'
Пример 2:
CSP Разрешение только JavaScript и изображений, размещенных на вашем сайте
Content-Security-Policy: script-src 'self'; img-src ‘self’;
Пример 3:
CSP Разрешить только JavaScript, размещенный на вашем сайте и cdn.trustedorigin.net, но изображения, размещенные везде
Content-Security-Policy: script-src 'self' cdn.trustedorigin.net; img-src *;
Пример 4:
CSP блокирует iFrames на вашем сайте
Content-Security-Policy: frame-src ‘none;’
Пример 5:
CSP блокирует отправку всех форм на вашем сайте
Content-Security-Policy form-action 'none';
Пример 6:
CSP разрешает только файл script.js на https://trustedorigin.net/ и значения по умолчанию для child-src, connect-src, font-src, frame-src, img-src, manifest-src, media- src, media-src, object-src, script-src, style-src и worker-src к источнику текущего URL
Content-Security-Policy default-src ‘self’; script-src https://trustedorigin.net/script.js;
При тестировании CSPA, о которых мы упоминали ранее, важно знать, что каждая политика имеет диспозицию: «применить» или «отчет».
Расположение «принудительно» применяет CSP, в то время как «отчет» позволяет разработчикам экспериментировать с политикой, фактически не применяя ее.
Это можно сделать, определив заголовок Content-Security-Policy-Report-Only вместо заголовка Content-Security-Policy и добавив директиву report- uri с URL-адресом, по которому вы хотели бы видеть отчеты о нарушениях CSP.
Идея здесь заключается в том, что вы можете исправить любое случайное нарушение вашей политики, прежде чем применять его.
Заголовок Content-Security-Policy-Report-Only не поддерживается внутри элемента.
Исправление предупреждений о смешанном содержимом с помощью CSP
Вы можете решить проблему предупреждений о смешанном содержимом с помощью CSP, определив директиву upgrade-insecure-requests, которая сделает всю тяжелую работу за вас.
Когда вы используете upgrade-insecure-requests в своем CSP, все HTTP-запросы обновляются браузером до HTTPS перед выполнением сетевых запросов.
Если на вашем сайте есть что-то вроде этого:
<img src=”http://awesomedomain.net/image.jpg”>
Это будет запрошено, как если бы это было так:
<img src="”https://awesomedomain.net/image.jpg”" />
Вы также можете сделать еще один шаг и добавить следующую директиву в свой CSP:
block-all-mixed-content
Как следует из названия директивы, она будет блокировать весь контент, недоступный через HTTPS.
Директивы upgrade-insecure-requests и block-all-mixed-content обеспечивают безопасность вашего сайта, поэтому они будут блокировать ресурсы. недоступен по HTTPS. Будьте осторожны с этими директивами, так как они могут нарушить работу вашего сайта.
Пожалуйста, помните, что браузеры, не соблюдающие CSP вашего сайта, все равно будут отображать предупреждения о смешанном содержании на вашем сайте. Это не следует считать полным решением проблемы. Вы можете узнать больше о том, как решить основную проблему предупреждений о смешанном содержимом, в этой записи блога и в нашем бесплатном руководстве Как установить SSL-сертификат.
Вывод
XSS-атаки могут быть чрезвычайно опасны для онлайн-бизнеса. Внедрение нежелательных вредоносных скриптов может привести к тому, что ваш сайт будет внесен в черный список Google или другими органами, занимающимися черными списками, и, как следствие, навредить репутации вашего бизнеса.
Очень важно понимать, что CSP не остановит злоумышленников от использования уязвимостей на вашем сайте. Но он не позволяет современным браузерам выполнять внедренные вредоносные скрипты, если они когда-либо внедряются на ваш сайт. Вы должны рассматривать CSP как еще один уровень защиты вашего веб-сайта, а не как единственную линию защиты.
Если вы ищете комплексное решение для обеспечения безопасности веб-сайтов, которое будет контролировать и защищать ваш веб-сайт, мы предлагаем Платформу безопасности веб-сайтов.
Первоначально опубликовано на сайте blog.sucuri.net 13 апреля 2018 г.
