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

The Content-Security-Policy мета-тег позволяет снизить риск XSS атаки, позволяя определить, где ресурсы могут быть загружены из, предотвращая браузеры от загрузки данных из любых других местах. Это затрудняет злоумышленнику внедрение вредоносного кода на ваш сайт.

я ударился головой о кирпичную стену, пытаясь понять, почему я получаю ошибки CSP один за другим, и, похоже, не было никаких кратких, четких инструкций о том, как именно это работает. Так вот моя попытка объяснить некоторые пункты CSP кратко, в основном концентрируясь на вещах, которые мне было трудно решить.

для краткости я не буду писать полный тег в каждом образце. Вместо этого я только покажу content свойство, так что образец, который говорит content="default-src 'self'" значит так:

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

1. Как разрешить несколько источников?

вы можете просто перечислить свои источники после директивы как пробел список:

content="default-src 'self' https://example.com/js/"

обратите внимание, что нет никаких кавычек вокруг параметров, кроме специальные, например,'self'. Кроме того, нет двоеточия (:) после директивы. Просто директива, затем разделенный пробелом список параметров.

все, что ниже указанных параметров неявно допускается. Это означает, что в приведенном выше примере это будут достоверные источники:

https://example.com/js/file.js
https://example.com/js/subdir/anotherfile.js

это, однако, не было бы действительно:

http://example.com/js/file.js
^^^^ wrong protocol

https://example.com/file.js
                   ^^ above the specified path

2. Как использовать разные директивы, что каждый из них делает?

наиболее распространенными директивами являются:

• default-src политика по умолчанию для загрузки javascript, изображений, CSS, шрифтов, AJAX-запросов и т. д
• script-src определяет допустимые источники для файлов javascript
• style-src определяет допустимые источники для файлов css
• img-src определяет допустимые источники для изображения
• connect-src определяет допустимые цели для XMLHttpRequest (AJAX), WebSockets или EventSource. Если попытка подключения сделана к хосту, который здесь не разрешен, браузер эмулирует 400

есть и другие, но это те, которые вам, скорее всего, понадобятся.

3. Как использовать несколько директив?

вы определяете все свои директивы внутри одного мета-тега, завершая их с помощью точка с запятой (;):

content="default-src 'self' https://example.com/js/; style-src 'self'"

4. Как обрабатывать порты?

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

content="default-src 'self' https://ajax.googleapis.com http://example.com:123/free/stuff/"

вышеизложенное приведет к:

https://ajax.googleapis.com:123
                           ^^^^ Not ok, wrong port

https://ajax.googleapis.com - OK

http://example.com/free/stuff/file.js
                 ^^ Not ok, only the port 123 is allowed

http://example.com:123/free/stuff/file.js - OK

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

content="default-src example.com:*"

5. Как обращаться с разными протоколы?

по умолчанию разрешены только стандартные протоколы. Например, чтобы разрешить веб-сокетов ws:// вам придется разрешить это явно:

content="default-src 'self'; connect-src ws:; style-src 'self'"
                                         ^^^ web sockets are now allowed on all domains and ports

6. Как разрешить файловый протокол file://?

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

content="default-src filesystem"

7. Как использовать встроенные скрипты и стиль определения?

если явно не разрешено, вы не можете использовать встроенные определения стилей, код внутри <script> теги или в свойствах тегов, таких как onclick. Вы позволяете им вот так:

content="script-src 'unsafe-inline'; style-src 'unsafe-inline'"

вы также должны явно разрешить встроенные, base64 закодированные изображения:

content="img-src data:"

8. Как разрешить eval()?

я уверен, что многие люди скажут, что вы этого не делаете, так как "eval-это зло" и наиболее вероятная причина для надвигающийся конец света. Эти люди были бы неправы. Конечно, вы можете определенно пробить большие дыры в безопасности вашего сайта с помощью eval, но у него есть совершенно правильные варианты использования. Вы просто должны быть умны в его использовании. Вы позволяете это так:

content="script-src 'unsafe-eval'"

9. Что именно делает 'self' в смысле?

вы можете взять 'self' означает localhost, локальную файловую систему или что-либо на том же хосте. Это ничего не значит. Это означает, что источники есть та же схема (протокол), тот же хост и тот же порт, что и файл, в котором определена политика содержимого. Обслуживание вашего сайта через HTTP? Нет https для вас тогда, если вы не определяете его явно.

я использовал 'self' в большинстве случаев, как это обычно имеет смысл включить его, но это не обязательно. Оставьте его, если он вам не нужен.

но подождите минутку! я не могу просто использовать content="default-src *" и покончим с этим?

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

content="default-src * 'unsafe-inline' 'unsafe-eval'"

... но я верю, что ты этого не сделаешь.

далее чтение:

http://content-security-policy.com

http://en.wikipedia.org/wiki/Content_Security_Policy