что такое csp для чего она нужна
CORS, CSP, HTTPS, HSTS: о технологиях веб-безопасности
Автор материала, перевод которого мы публикуем сегодня, говорит, что существует множество причин изучать веб-безопасность. Например, вопросами безопасности интересуются пользователи веб-сайтов, которых беспокоит возможность кражи их персональных данных. Безопасность заботит веб-разработчиков, которые стремятся к повышению уровня защиты создаваемых ими проектов. То же самое можно сказать и о начинающих программистах, которые ищут работу и готовятся к собеседованиям. Цель этой статьи заключается в том, чтобы понятным языком рассказать о некоторых важных технологиях веб-безопасности. Прежде чем приступить к разговору об этих технологиях, при упоминании которых обычно оперируют сокращениями вроде CORS, CSP и HSTS, рассмотрим пару базовых концепций безопасности.
Две базовых концепции веб-безопасности
▍100% защита — это миф
В мире безопасности нет такого понятия, как «100% защита от взлома». Если кто-нибудь когда-нибудь скажет вам о таком уровне защиты, знайте, что он ошибается.
▍Одного уровня защиты недостаточно
Предположим, некто полагает, что реализовав CSP, он полностью защитил свой проект от XSS-атак. Возможно, кто-то воспринимает то, что абсолютной защиты не существует, как данность, но мысли, подобные вышеописанной, могут посетить кого угодно. Если вести речь о программистах, которые решили разобраться в вопросах безопасности, то, возможно, причиной возникновения таких мыслей является тот факт, что, при написании программного кода, они, в основном, оперируют такими понятиями, как «чёрное» и «белое», 1 и 0, «истинно» и «ложно». Но в безопасности не всё так просто.
Технологии веб-безопасности
Начнём разговор о веб-безопасности с технологии, на которую разработчики обычно обращают внимание очень рано, скажем, в самом начале своего профессионального пути. Кстати, если задаться целью обхода этого метода защиты, на StackOverflow можно найти массу сведений о том, как это сделать. Речь идёт о CORS.
Видели когда-нибудь такую ошибку:
Встретившись с подобным, вы думаете, что вы, уж точно, не первый, с кем это случилось. Погуглив, вы выясняете, что, для того, чтобы эту проблему решить, достаточно установить некое расширение. Ну не замечательно ли? Однако технология CORS (Cross-Origin Resource Sharing, совместное использование ресурсов между разными источниками) существует не для того, чтобы мешать разработчикам, а для того, чтобы защищать их проекты.
Для того чтобы понять, как CORS позволяет защищать веб-проекты, сначала поговорим о куки-файлах, в частности — о куки, используемых для аутентификации пользователей. Подобные куки используются, при работе с неким веб-ресурсом, для того, чтобы сообщить серверу о том, что пользователь вошёл в систему. Они автоматически отправляются с запросами, выполняемыми к соответствующему серверу.
В мире, где не было бы CORS, скрипт с superevilwebsite.rocks мог бы скрытно внести изменения в ваш FB-профиль, мог бы украсть какую-то информацию, со всеми вытекающими отсюда последствиями. В таком мире легко могла бы возникнуть «эпидемия superevilwebsite.rocks», когда скрипт, захватывающий управление аккаунтом пользователя, публикует на его странице ссылку, перейдя по которой друзья этого пользователя, «заражаются» сами, а через ссылки, опубликованные на их страницах, эпидемия, в итоге, охватывает весь Facebook.
Тут у вас может возникнуть следующий вопрос: «Но ведь superevilwebsite.rocks может просто изменить заголовок источника в своих запросах, и они будут выглядеть так, будто идут от facebook.com?».
Мошеннический сайт может попытаться это сделать, но у него ничего не получится, так как браузер будет игнорировать подобный заголовок и использовать реальные данные.
«А что если superevilwebsite.rocks выполнит подобный запрос с сервера?», — спросите вы.
В подобной ситуации CORS можно обойти, но никакого толку от этого не будет, так как, выполняя запрос с сервера, нельзя будет передать Facebook аутентификационный куки-файл. Поэтому скрипту, для успешного выполнения подобного запроса, необходимо выполняться на стороне клиента и иметь доступ к куки-файлам, хранящимся на клиенте.
Для того чтобы разобраться в том, что такое CSP (Content Security Policy, политика защиты контента), сначала надо поговорить об одной из самых распространённых веб-уязвимостей. Речь идёт о XSS (cross-site scripting, межсайтовый скриптинг).
При выполнении XSS-атаки злоумышленник внедряет специальный JavaScript-код в клиентскую часть некоего сайта. Можно подумать: «Ну и что будет делать этот скрипт? Менять цвета элементов страниц?».
Предположим, что некто успешно внедрил свой JS-скрипт в страницы сайта, на который вы зашли. Что опасного может сделать подобный скрипт? На самом деле, много всего:
Content Security Policy (CSP)
CSP разрабатывался с возможностью полной обратной совместимости (за исключением CSP version 2, в которой были намеренно определены некоторые противоречия блокирующие обратную совместимость; с деталями можно ознакомиться здесь, в пункте 1.1). Браузеры, которые не поддерживают CSP, все ещё могут работать с серверами, которые поддерживают CSP, и наоборот: браузеры, в которых поддержка CSP отсутствует, будут её игнорировать, продолжая работу в соответствии со стандартными правилами ограничения домена для загрузки контента. В случае, если сайт не предоставляет CSP-заголовки, браузеры, в свою очередь, будут использовать стандартные правила ограничения домена.
Угрозы
Межсайтовый скриптинг
Основная цель создания CSP заключается в устранении XSS-атак и сборе данных об их попытках. XSS-атаки используют доверие браузера к контенту, полученному с сервера. Зловредные скрипты исполняются в браузере жертвы, поскольку браузер доверяет источнику, даже когда скрипт поставляется не оттуда, откуда кажется.
CSP даёт возможность администраторам серверов снизить или полностью устранить вектора, по которым злоумышленники могут провести XSS, с помощью определения доменов, которые браузер клиента должен считать доверенными источниками исполняемых скриптов. В таком случае, браузер, совместимый с CSP, будет исполнять только те скрипты, которые были получены из списка разрешённых источников, и игнорировать прочие (в т.ч. встраиваемые скрипты и обработчики событий, указанные непосредственно в HTML-атрибутах).
В качестве крайней меры защиты, сайты, которые хотят запретить исполнение скриптов, могут настроить это поведение глобально, с помощью соответствующей опции.
Пакетный сниффинг
В дополнение к ограничению количества доверенных доменов, с которых разрешается получать контент, можно также ограничить список используемых протоколов; например (в идеале и это крайне желательно с точки зрения обеспечения безопасности), сервер может поставить ограничение на получение контента только по HTTPS. Завершённая стратегия защиты передачи данных должна включать в себя не только принуждение к использованию HTTPS, но также и пометку всех кук с помощью специального флага, а также перенаправление запросов с HTTP на HTTPS. Сайты также могут использовать Strict-Transport-Security HTTP-заголовок, чтобы обеспечить подключение к ним браузеров только по защищённому каналу.
Использование CSP
Настройка CSP включает в себя добавление на страницу HTTP-заголовка Content-Security-Policy (en-US) и его настройку в соответствии со списком доверенных источников, из которых пользователь может получать контент. Например, страница, на которой происходит загрузка и отображение изображений может разрешать их получение из любых источников, но ограничить отправку данных формы конкретным адресом. При правильной настройке, Content Security Policy поможет защитить страницу от атак межсайтового скриптинга. Данная статья описывает как правильно настроить необходимые заголовки и примеры, как это сделать.
Определение политики
Вы можете начать настройку Content-Security-Policy (en-US) с определения HTTP-заголовка и указания какую политику использовать:
Создание политики
Примеры: Распространённые случаи применения
В данном разделе приводятся наиболее распространённые сценарии использования CSP.
Пример 1
Вы хотите ограничить источники контента только исходным сервером (исключая поддомены)
Пример 2
Вы хотите разрешить получение контента с доверенного домена и всех его поддоменов (доверенный домен не обязательно должен совпадать с тем, на котором настраиваются CSP.)
Пример 3
Вы хотите разрешить пользователям приложения вставлять в создаваемый ими контент картинки из любого источника, но при этом ограничить источники аудио- и видео-файлов списком доверенных провайдеров. Получение скриптов должно происходить только с конкретного сервера, содержащего доверенный код.
При такой настройке, весь контент доступен для получения только с исходного домена, со следующими исключениями:
Пример 4
Вы хотите удостовериться, что весь получаемый контент для онлайн-банкинга идёт по SSL и атакующий не сможет обрабатывать запросы:
Пример 5
Для просмотра писем в почтовом клиенте вы хотите разрешить использование HTML внутри письма, а также позволить загрузку изображений из любых источников, но запретить использование любого JavaScript-кода и прочий потенциально опасный контент.
Заметьте, что в настройке политики отсутствует директива script-src (en-US); при такой настройке CSP при загрузке скриптов будут использоваться настройки, определяемые директивой default-src (en-US), следовательно все скрипты могут быть загружены только с исходного домена.
Тестирование настройки политики
Для облегчения развёртывания можно настроить развёртывание CSP в режиме report-only. Таким образом, политика не будет ограничивать загрузку, но будет сообщать обо всех нарушениях на указанный в заголовке URI. Кроме того, заголовок report-only может использоваться для тестирования новой политики без полноценного развёртывания.
Для определения вашей политики вы можете использовать заголовок Content-Security-Policy-Report-Only (en-US) следующим образом:
Настройка отправки отчётов
По умолчанию, отправка отчётов не производится. Для того чтобы включить отправку отчётов, необходимо в вашей политике определить директиву report-uri (en-US) и указать как минимум один URI, куда будут направляться отчёты:
Кроме того, необходимо настроить свой сервер на получение этих отчётов; вы можете хранить и обрабатывать эти отчёты как считаете нужным.
Синтаксис отчёта о происшествиях
Объект отчёта в формате JSON содержит следующие поля:
Пример отчёта о происшествии
Совместимость с браузерами
BCD tables only load in the browser
Для некоторых версий Safari существует специфическая несовместимость реализации CSP. Если установить заголовок Content Security Policy без заголовка Same Origin, то браузер начнёт блокировать и создавать ложно-положительные отчёты о нарушении политики для всего контента, как с запрашиваемого источника, так и из внешних источников.
Всё, что нужно знать о КриптоПро CSP
Бумажный документооборот уходит в прошлое. Постепенно взаимодействие между юридическими лицами, государственными органами и даже физлицами переходит в электронный вид. Но подписывать электронные документы по-прежнему надо. Только не собственноручной подписью, а электронной.
Все, кто знаком с юридически значимым электронным документооборотом и технологией электронной подписи, слышали о КриптоПро. Рассказываем что это такое, зачем нужно, где применяется и как установить.
Компания КриптоПро что это и зачем
КриптоПро – это компания-лидер на рынке средств криптографической защиты информации. Программные и аппаратные продукты КриптоПро применяются государственными органами и коммерческими организациями для работы в системах электронного документооборота.
КриптоПро – это компания c большим опытом по разработке софта для информационной защиты на базе СКЗИ – криптографических технологий.
Поэтому на вопрос «КриптоПро: что это и зачем?» ответить просто: к услугам компании прибегают, когда нужно купить софт для сохранения конфиденциальности информации, что необходимо при её передаче в сети интернет.
КриптоПро CSP: что это за программа
Самым распространённым решением для работы с электронной подписью является программа КриптоПро CSP.
Программное обеспечение КриптоПро CSP – это обязательный атрибут ЮЗЭДО, который называют средством электронной подписи. Оно нужно для создания и проверки ЭП согласно 63-ФЗ.
Программа КриптоПро CSP также называется криптопровайдером, то есть программой для осуществления криптографической защиты. Аббревиатура CSP расшифровывается на английском языке как «cryptography service provider». Криптопровайдер зашифровывает информацию, благодаря чему сохраняется конфиденциальность данных при передаче в сети Интернет.
Под криптопровайдером также понимается модуль в ОС компьютера владельца ЭП, который позволяет осуществлять криптографические операции: создание подписи, зашифровку и защиту данных.
Алгоритм работы программы
Итак, криптопровайдер устанавливается на компьютер пользователя ЭП. Что делается программой? Она обращается к сертификату ЭП на компьютере, токене или других носителях и подписывает документы.
Стоит помнить, что сама по себе ЭП неполноценна без закрытого ключа и настройки ключевой связки. Поэтому CSP КриптоПро сначала проверяет подпись, подтверждает её корректность. Потом зашифровывает и отправляет документ.
Программное обеспечение разработчика есть в двух частях: клиентское и серверное. Первое устанавливается на компьютер пользователя. Второе – на сервер организации.
Для чего нужна программа КриптоПро CSP
Ответить на вопрос, для чего понадобится КриптоПро CSP, просто. Это все случаи, когда требуется применение именно усиленной квалифицированной ЭП, а не какой-либо ещё.
Приведём лишь неполный список, для чего она нужна:
— для работы на государственных порталах;
— отправки отчётности в налоговую и другие госорганы;
— для регистрации онлайн-кассы в налоговой;
— для работы с ЕГАИС, маркировкой и ФГИС Меркурий;
— электронного документооборота с контрагентами;
— участия в электронных торгах.
Что КриптоПро умеет
Итак, КриптоПро – это программа, которая шифрует, защищает информацию, а также хранит секретные ключи. Вот полный список, того, для чего эта программа нужна:
— создание ключа ЭП и его проверки;
— шифрование данных и сохранение их конфиденциальности при передаче;
— аутентичность соединений и протоколов;
— контроль целостности ПО на ПК;
— защита от внешних проникновений и нелегальных изменений в пользовательской информации.
Как установить программу
Нужной версией КриптоПро CSP на сегодняшний день является издание не ниже 4.0. Именно оно и последующие являются сертифицированными для работы с квалифицированным сертификатом ключа проверки ЭП.
Нужную версию программы – 4.0 – можно скачать двумя способами.
Первый – с сайта компании-разработчика. Для загрузки нужно зарегистрироваться на сайте.
Второй – в личном кабинете компании Такском. После входа в ЛК нужно перейти в раздел «Управление услугами» → «АРМ» → «Плагины, дополнения» → «Утилита установки КриптоПро». Для загрузки надо ввести логин и пароль (находятся в «Карточке настройки ПО для представления отчётности»).
Во время установки требуется принять условия лицензионного соглашения. По завершению установки программы – перезагрузить компьютер.
Отметим также, что использование программы бесплатно можно только в течение тестового периода – три месяца. В дальнейшем нужно приобрести лицензию на программу CSP КриптоПро. Приобретать её лучше заблаговременно.
Если лицензия куплена, то в процессе установки нужной версии КриптоПро CSP потребуется ввод серийного номера с бланка лицензии.
FAQ и инструкцию по установке можно посмотреть здесь, на странице техподдержки. На этой же странице вы найдёте ответы на такие вопросы:
— Срок действия КриптоПро истёк – что это?
— Как обновить КриптоПро CSP и что для этого нужно?
— Куда вводить серийный номер лицензии?
— Как удалить КриптоПро типа CSP?
— Как установить личный сертификат КриптоПро и что это за процедура?
Приобрести лицензию на программу можно у Такском
Такском имеет статус официального дилера продуктов торговой марки КриптоПро. Статус даёт право на распространение, внедрение и сопровождение программ для ЭВМ. Сведения о Такском как об официальном дилере числятся в списке партнёров на о сайте КриптоПро.
Такском является одним из ведущих операторов ЭДО, а его Удостоверяющий центр — крупнейший аккредитованный центр по выдаче сертификатов ЭП в России.
Лицензию КриптоПро CSP можно приобрести в УЦ Такском. Нужную версию КриптоПро CSP уточняйте в специальном разделе сайта. Такском предлагает как клиентские, так и серверные решения, сроком на год или бессрочные.
Итак, мы уже сказали, что нужную КриптоПро CSP лицензию можно купить у Такском. Это делается в 4 простых шага:
— В разделе «Средства защиты информации и токены» выбираете тот тип лицензии, что нужен вам, и нажимаете «В корзину».
— Заполняете регистрационную карту и отправляете её.
— На указанный вами адрес электронной почты поступят счета на оплату и инструкции по получению серийного номера лицензии на КриптоПро типа CSP.
Программа КриптоПро – далеко не единственный инструмент для работы, который предоставляет Такском. На сайте компании можно выбрать электронную подпись. В каталоге компании есть ЭП для различных целей и площадок: для участиях в торгах, получения госуслуг и сдачи отчётности, систем ЭДО и для физических лиц. Также компания реализует защищённые носители (токены). Каждый посетитель сайта найдёт то, что ему нужно. Если нет – специалисты техподдержки Такском с удовольствием ответят на все возникшие вопросы.
Улучшение сетевой безопасности с помощью Content Security Policy
Content Security Policy (CSP, политика защиты контента) — это механизм обеспечения безопасности, с помощью которого можно защищаться от атак с внедрением контента, например, межсайтового скриптинга (XSS, cross site scripting). CSP описывает безопасные источники загрузки ресурсов, устанавливает правила использования встроенных стилей, скриптов, а также динамической оценки JavaScript — например, с помощью eval. Загрузка с ресурсов, не входящих в «белый список», блокируется.
Принцип действия
CSP сейчас является кандидатом в рекомендации консорциума W3C. Для использования политики страница должна содержать HTTP-заголовок Content-Security-Policy с одной и более директивами, которые представляют собой «белые списки». В версии 1.0 поддерживаются следующие директивы:
Для всех директив действуют следующие правила:
Content-Security-Policy: default-src ‘self’;
Попытка загрузки ресурсов из иных доменов будут пресекаться браузером с выдачей уведомления в консоли:
По умолчанию CSP ограничивает исполнение JavaScript путём запрета встроенных скриптов и динамической оценки кода. В комбинации с «белыми списками» это позволяет предотвращать атаки с внедрением контента. Например, XSS-атаку с внедрением тэга инлайн-скрипта:
Загрузка внешних скриптов, которые не включены в CSP, также будет пресечена:
На данный момент в перечне URL нельзя прописывать пути ( http://cdn.example.com/path ), можно лишь перечислять сами домены ( http://cdn.example.com ). Зато поддерживаются символы подстановки, так что вы можете описать сразу все поддомены ( http://*.example.com ).
Поддержка браузерами
Получение отчётов о нарушениях CSP
Допустим, у нас есть такая CSP:
Это означает, что браузер может загружать ресурсы только с нашего собственного домена. Но нам нужно использовать сервис Google Analytics, который будет пытаться скачивать JavaScript с www.google-analytics.com. А это уже нарушение нашей CSP. В этом случае report-uri отправит запрос со следующим JSON:
Content-Security-Policy-Report-Only
Прописывание заголовка
HTTP-заголовок можно прописать прямо в конфигурационных файлах на сервере:
Также многие языки программирования и фреймворки позволяют добавлять заголовки программно (например, PHP, Node.js):
CSP в дикой природе
Давайте посмотрим, как CSP внедрён в Facebook:
А теперь вариант Twitter:
CSP Level 2
Также является кандидатом в рекомендации. В CSP Level 2 сделаны следующий нововведения:
Nonce — это генерируемая случайным образом на сервере строковая переменная. Она добавляется в CSP-заголовок:
и в тэг инлайн-скрипта:
Пример хэша, сгенерированного из строковой console.log(‘Hello, SitePoint’); с помощью алгоритма Sha256 (base64).
Во время рендеринга страницы браузер для каждого инлайн-скрипта вычисляет хэши и сравнивает с перечисленными в CSP. Приведённый выше хэш позволяет выполнить скрипт:
Использование политики безопасности контента (CSP) для защиты веб-приложений
Политика безопасности контента (Content Security Policy — CSP) — это стандарт компьютерной безопасности, обеспечивающий дополнительный уровень защиты от межсайтовых сценариев (XSS), clickjacking (перехвата кликов) и других атак с использованием кода, основанных на выполнении вредоносного контента в контексте доверенной веб-страницы. Используя подходящие директивы CSP в заголовках ответа HTTP, вы можете выборочно указать, какие источники данных должны быть разрешены в вашем веб-приложении. В этой статье описано, как использовать заголовки CSP для защиты сайтов от атак XSS и других попыток обойти политику CSP.
Зачем нам нужен CSP?
В то же время злоумышленники используют атаки с использованием 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 разных имени заголовка политики безопасности контента, в зависимости от браузера и времени принятия:
Использование директив CSP
CSP позволяет определять различные ограничения содержимого с помощью директив, обычно указанных в заголовках ответа HTTP. Вот пример добавления заголовков CSP на веб-сервер Apache:
При необходимости вы также можете указать желаемые директивы на уровне страницы, используя метатеги HTML. Вот пример, который устанавливает ту же политику, что и выше:
Каждая директива состоит из имени, за которым следует одно или несколько значений, и заканчивается точкой с запятой. Вы можете использовать подстановочный знак * для обобщения целых значений, поддоменов, схем и портов:
Этот заголовок позволяет использовать источники из любого субдомена example.com (но не самого example.com) по любой схеме (http, https и т.д.).
Официальная рекомендация W3C содержит полный список директив с более формальными определениями, но следующий обзор должен дать вам хорошее представление о наиболее часто используемых.
Директивы белого списка источников
Основной целью CSP является ограничение источников веб-контента, поэтому существует множество директив для указания разрешенных источников для различных типов ресурсов. Как только заголовок Content-Security-Policy указан, браузер будет отклонять любой контент из источников, которые явно не занесены в белый список, с использованием любой из приведенных ниже директив. Исходные значения разделены пробелами и могут включать как URL-адреса, так и специальные ключевые слова ‘none’, ‘self’, ‘unsafe-inline’ и ‘unsafe-eval’ (подробно обсуждается ниже). Обратите внимание, что каждая директива может быть указана только один раз в том же заголовке, а ключевые слова должны быть введены в одинарные кавычки.
Написание JavaScript и CSS с CSP
Встроенный код является основным вектором нападения, потому что он всегда выполняется в текущем контексте, поэтому его нельзя ограничивать. Когда CSP включен, он блокирует весь встроенный код по умолчанию. Это означает, что никаких встроенных стилей или встроенных сценариев не должно существовать, включая встроенные обработчики событий или javascript: URL поэтому любой новый код должен следовать передовым методам использования исключительно внешних файлов сценариев и стилей. Ключевое слово unsafe-inline разрешает встроенный код для всех или некоторых источников скриптов, но W3C рекомендует избегать его, где это возможно.
Например, страница HTML и JavaScript старого стиля может содержать код сценария как в тегах Want to click the button?
Чтобы преобразовать это в современный и совместимый с CSP стиль, поместите сценарий в отдельный файл и используйте HTML чисто декларативно, что-то вроде:
Даже после того, как типичные векторы атак были заблокированы, злоумышленники все равно могут выполнить сценарий, если используется динамически запускаемый (evaluated) код. Вот почему CSP также блокирует все функции запуска строк по умолчанию, включая eval (), new Function (), setTimeout ([string]) и аналогичные конструкции. Это приводит к нескольким изменениям в практике кодирования, включая использование JSON.parse () вместо eval() для анализа данных JSON.
Подобно unsafe-inline, вы можете использовать ключевое слово unsafe-eval, чтобы разрешить запуск кода для некоторых или всех источников. Опять же, это противоречит лучшей практике для современного кода и должно использоваться только для устаревшего кода, который не может быть реорганизован.
Nonces и Hashes чтобы разрешить встроенные скрипты
Если вам абсолютно необходимо сделать исключение для некоторого унаследованного встроенного кода, который нельзя перенести в отдельный файл, CSP предоставляет две функции, позволяющие разрешать определенные блоки кода, не прибегая к unsafe-inline. Для внесения в белый список определенного фрагмента кода вы можете использовать nonce (одноразовый) номер (уникальный одноразовый идентификатор) для тега
Чтобы разрешить этот конкретный тег сценария, используйте:
Генерация nonce номера для каждой загрузки страницы может быть проблематичным, поэтому другой подход заключается в использовании криптографического хэша самого разрешенного кода. Для этого начните с вычисления хэша SHA для всех символов внутри тега
Тогда директива, использующая хэш SHA256 этого кода:
Директивы CSP на уровне страницы
Помимо источников контента, внесенных в белый список, CSP также может налагать ограничения на действия, которые может выполнять текущая страница. Чтобы использовать эту функцию, используйте директиву sandbox, чтобы обрабатывать страницу так, как если бы она находилась внутри изолированного фрейма. Полное описание ограничений, накладываемых песочницей на страницу, см. в разделе Sandboxing в спецификации HTML5.
Чтобы повысить безопасность старых сайтов с большим количеством устаревших HTTP-страниц, вы можете использовать директиву upgrade-insecure-requests для перезаписи небезопасных URL-адресов. Это дает указание агентам пользователя изменять HTTP на HTTPS в схемах URL-адресов и может иметь неоценимое значение, если у вас все еще есть несколько URL-адресов HTTP.
Политика тестирования и мониторинг нарушений
Политика безопасности контента предоставляет мощные функциональные возможности для контроля источников контента и поведения страниц. Однако это также означает, что одна неправильно настроенная директива может сделать сайт частично или полностью недоступным для посетителей, поэтому вам нужен способ безопасного тестирования директив.
Прежде чем начать работу с директивами CSP, вы можете использовать заголовок Content-Security-Policy-Report-Only вместо Content-Security-Policy. В режиме report-only браузер будет отслеживать политику и сообщать о нарушениях, но фактически не применяет ограничения. Используйте директиву report-uri, чтобы сообщить браузеру, где он должен публиковать отчеты о нарушениях в формате JSON. Это может быть любой локальный или внешний URI, например:
Обратите внимание, что вы можете комбинировать заголовки Content-Security-Policy-Report-Only и Content-Security-Policy, чтобы протестировать новую политику, при этом применяя существующую.
После того, как политика активна, вы можете использовать ту же директиву report-uri для получения подробных отчетов о нарушениях политики. Каждый отчет JSON начинается с атрибута csp-report и выглядит примерно так:
Как видите, отчеты предоставляют информацию о каждом нарушении политики, включая заблокированный URI и нарушенную директиву. Это значительно упрощает устранение неполадок, особенно для политик с сотнями директив и значений.
Поддержка Content Security Policy в Netsparker
В течение последних нескольких лет CSP Level 2 был реализован во всех современных браузерах и широко используется в Интернете как эффективный способ снижения риска XSS. Чтобы отразить это, Netsparker проверяет наличие HTTP-заголовков Content-Security-Policy и сообщает об уязвимости «Best Practice», если они отсутствуют.
Однако простого наличия заголовка CSP недостаточно, поскольку недопустимые директивы будут игнорироваться браузерами (и, следовательно, неэффективны), в то время как небезопасные значения директив не обеспечат ожидаемый уровень защиты. Netsparker выполняет более 20 подробных проверок, чтобы убедиться, что директивы используют правильный синтаксис в сочетании со значениями, обеспечивающими эффективную безопасность. См. Vulnerability Index для получения полного списка проверок CSP, доступных в Netsparker.
Демонстрация Content Security Policy в действии
И, наконец, для практической демонстрации настройки заголовков CSP посмотрите это еженедельное интервью по безопасности с исследователем безопасности Netsparker Свеном Моргенротом. Разговаривая с Полом Асадуряном, Свен рассказывает о проблемах, которые CSP предназначен для решения, и показывает практическую демонстрацию заголовков CSP в действии.