Политика безопасности контента ( CSP ) — это стандарт компьютерной безопасности , введенный для предотвращения межсайтового скриптинга (XSS), кликджекинга и других атак с внедрением кода, возникающих в результате выполнения вредоносного контента в контексте доверенной веб-страницы . [1] Это кандидат на рекомендацию рабочей группы W3C по безопасности веб-приложений, [2] широко поддерживаемый современными веб-браузерами . [3] CSP предоставляет владельцам веб-сайтов стандартный метод объявления одобренных источников контента, который браузерам должно быть разрешено загружать на этот веб-сайт — охватываемые типы: JavaScript , CSS , HTML-фреймы , веб-работники , шрифты , изображения, встраиваемые объекты, такие как Java-апплеты , ActiveX , аудио- и видеофайлы, а также другие функции HTML5 .
Стандарт, первоначально названный Content Restrictions, был предложен Робертом Хансеном в 2004 году [4] , впервые реализован в Firefox 4 и быстро подхвачен другими браузерами. Версия 1 стандарта была опубликована в 2012 году как рекомендация-кандидат W3C [5] и быстро с последующими версиями (Уровень 2), опубликованными в 2014 году. По состоянию на 2023 год [обновлять], проект Уровня 3 разрабатывается с новыми функциями, которые быстро принимаются веб-браузерами. [6]
Следующие имена заголовков используются в рамках экспериментальных реализаций CSP: [3]
Content-Security-Policy– стандартное имя заголовка, предложенное документом W3C. Google Chrome поддерживает это с версии 25. [7] Firefox поддерживает это с версии 23, [8] выпущенной 6 августа 2013 года. [9] WebKit поддерживает это с версии 528 (ночная сборка). [10] Поддержка Microsoft Edge на основе Chromium аналогична поддержке Chrome. [11]X-WebKit-CSP– устаревший экспериментальный заголовок, введенный в Google Chrome , Safari и другие веб-браузеры на базе WebKit в 2011 году. [12]X-Content-Security-Policy– устаревший, экспериментальный заголовок, представленный в браузерах на базе Gecko 2 (Firefox 4 – Firefox 22, Thunderbird 3.3, SeaMonkey 2.1). [13]Веб-сайт может объявлять несколько заголовков CSP, также смешивая заголовки принудительного исполнения и только для отчетов. Каждый заголовок будет обрабатываться браузером отдельно.
CSP также может быть доставлен в HTML-коде с использованием метатега , хотя в этом случае его эффективность будет ограничена. [14]
Internet Explorer 10 и Internet Explorer 11 также поддерживают CSP, но только директиву sandbox, используя экспериментальный X-Content-Security-Policyзаголовок. [15]
Ряд фреймворков веб-приложений поддерживают CSP, например, AngularJS [16] (встроенный) и Django (промежуточное ПО). [17] Инструкции для Ruby on Rails были опубликованы на GitHub . [18] Однако поддержка веб-фреймворка требуется только в том случае, если содержимое CSP каким-то образом зависит от состояния веб-приложения, например, от использования источника nonce. В противном случае CSP довольно статичен и может быть доставлен с уровней веб-приложений выше приложения, например, на балансировщике нагрузки или веб-сервере .
В декабре 2015 г. [19] и декабре 2016 г. [20] были опубликованы несколько методов обхода 'nonce'источников разрешенных списков. В январе 2016 г. [21] был опубликован еще один метод, который использует разрешенный список CSP на уровне сервера для эксплуатации старых и уязвимых версий библиотек JavaScript, размещенных на том же сервере (частый случай с серверами CDN). В мае 2017 г. [22] был опубликован еще один метод обхода CSP с использованием кода фреймворков веб-приложений.
Если Content-Security-Policyзаголовок присутствует в ответе сервера, то соответствующий клиент применяет политику декларативного списка разрешений. Одним из примеров цели политики является более строгий режим выполнения для JavaScript, чтобы предотвратить определенные атаки межсайтового скриптинга. На практике это означает, что ряд функций отключены по умолчанию:
<script>блоки, [б]onclick)javascript:<style>блок [б]styleприписывается элементам HTMLeval()setTimeoutиsetIntervalnew Function()конструкторCSSStyleSheet.insertRule()методХотя использование CSP в новом приложении может быть довольно простым, особенно с совместимой с CSP инфраструктурой JavaScript , [d] существующие приложения могут потребовать некоторого рефакторинга — или смягчения политики. Рекомендуемая практика кодирования для совместимых с CSP веб-приложений — загрузка кода из внешних исходных файлов ( <script src>), разбор JSON вместо его оценки и использование EventTarget.addEventListener()для установки обработчиков событий. [23]
'unsafe-inline'оператора.<script>и <style>блоки могут быть индивидуально добавлены в разрешенный список в CSP с помощью операторов nonceили hash.'unsafe-eval'оператора.<html ng-app ng-csp>Каждый раз, когда запрошенный ресурс или выполнение скрипта нарушает политику, браузер отправляет POSTзапрос по значению, указанному в report-uri[24] или report-to[25], содержащему сведения о нарушении.
Отчеты CSP представляют собой стандартные структуры JSON и могут быть получены либо с помощью собственного API приложения [26], либо с помощью общедоступных приемников отчетов CSP. [ необходима ссылка ]
В 2018 году исследователи безопасности показали, как отправлять ложные положительные отчеты назначенному получателю, указанному в report-uri. Это позволяет потенциальным злоумышленникам произвольно активировать эти сигналы тревоги и может сделать их менее полезными в случае реальной атаки. [27] Такое поведение является намеренным и не может быть исправлено, поскольку отчеты отправляет браузер (клиент).
Согласно исходной модели обработки CSP (1.0) (2012–2013 гг.), [28] CSP не должна вмешиваться в работу надстроек или расширений браузера, установленных пользователем. Эта функция CSP фактически позволила бы любой надстройке, расширению или Bookmarklet внедрять скрипт на веб-сайты, независимо от происхождения этого скрипта, и, таким образом, быть освобожденной от политик CSP.
Однако эта политика с тех пор была изменена (начиная с CSP 1.1 [29] ) со следующей формулировкой. Обратите внимание на использование слова «может» вместо прежней абсолютной формулировки «не следует»:
Примечание: Пользовательские агенты могут разрешать пользователям изменять или обходить принудительное применение политики с помощью пользовательских настроек, букмарклетов, сторонних дополнений к пользовательскому агенту и других подобных механизмов.
Абсолютная формулировка «должен» использовалась пользователями браузеров для запроса/требования соблюдения политики и установки изменений в популярных браузерах (Firefox, Chrome, Safari) для ее поддержки. Это было особенно спорно, когда такие сайты, как Twitter и GitHub, начали использовать строгие политики CSP, которые «сломали» использование Bookmarklets. [30]
Рабочая группа W3C по безопасности веб-приложений считает, что такой скрипт является частью Trusted Computing Base, реализуемой браузером; однако представитель Cox Communications заявил рабочей группе , что это исключение является потенциальной дырой в безопасности, которая может быть использована вредоносными или скомпрометированными дополнениями или расширениями. [31] [32]
По состоянию на 2015 год [обновлять]W3C предлагает ряд новых стандартов безопасности браузеров, большинство из которых дополняют CSP: [33]
Политика безопасности контента предназначена для того, чтобы помочь веб-дизайнерам или администраторам серверов указать, как контент взаимодействует на их веб-сайтах. Она помогает смягчить и обнаружить такие типы атак, как XSS и инъекция данных.
Ограничения контента — способ для веб-сайтов сообщить браузеру о необходимости повысить уровень безопасности на страницах, где сайт знает, что контент отправлен пользователем и, следовательно, потенциально опасен.