Content-Security-Policy: host-source VS 'self': в чем разница?

Question

[ifap]

Курил доки, много думал, но так и не придумал: в каком сценарии может потребоваться указание источника загрузки как 'self' вместо конкретного сайта(ов)? Мы заранее не знаем, с какого сайта может загружаться контент? А в чем тогда смысл применения CSP?

И, чтобы два раза не вставать, почему ни host-source, ни 'self' в качестве источника не включают «подмножество» 'unsafe-inline', т.е. контент, встроенный в загружаемую страницу? Саму страницу грузить можно, вызываемый с нее скрипт/стиль на том же домене – можно, ML-элементы страницы со стилевыми свойствами (со скриптами не проверял) – снова можно, а тот же самый скрипт/стиль, если он встроен отдельным куском – нет, где логика?

Comments

[CityCat4]

Указали бы правильные теги - глядишь больше бы народу прочитало, кто в теме. Веб-разработка - это только часть ИБ, причем не самая большая.

Answer 1

[granty]

Мы заранее не знаем, с какого сайта может загружаться контент?

Знаем, но не всегда. У сайта может быть множество поддоменов, в том числе и динамических.

host-source VS 'self'
Вместо 'self' браузер подставляет протокол, хост(домен) и номер порта от источника происхождения (текущего URL) страницы.
Если у вас сайт доступен как: http://domain.com, https://domain.com, http://www.domain.com, https://www.domain.com, http://www.domain.com:8081 - 'self' всё это покроет:
зайдёте на http://www.domain.com:8080/page.html - 'self' будет равен http://www.domain.com:8080, и тп.

Иначе вместо 'self' вам придётся перечислять все варианты имён хостов(включая поддомены) со схемами/протоколами и номерами портов.

почему ни host-source, ни 'self' в качестве источника не включают «подмножество» 'unsafe-inline', т.е. контент, встроенный в загружаемую страницу?

Потому, что такой встроенный скрипт может появиться на странице без ведома вебмастера. Его может вставить вредоносный браузерный плагин, другой скрипт (например, виджет погоды), его может вставить интернет-провайдер. Такой инлайн-скрипт может появиться на странице в результате XSS-уязвимости.

Content Security Policy от этого и защищает.

Comments

[ifap]

У сайта может быть множество поддоменов, в том числе и динамических.

Можно задать something-src *.domain.com, что покроет все подмножество поддоменов известного нам домена. А запрет неизвестных - в этом же и суть CSP...

Потому, что такой встроенный скрипт может появиться на странице без ведома вебмастера.

Вы несколько выдрали из контекста, мой вопрос был скорее про почему, например, <img style="something"> - можно, согласно одному лишь default-src domain.com, а <style>something</style> в том же самом HTML-файле - нет, надо дописывать unsafe-inline? Уж если злоумышленник может модифицировать наш HTML-файл, то ему фиолетово, как именно XSSить.

Я понимаю, как это работает, я не понимаю почему и где логика, не нарушающая саму идею CSP?

[granty]

ifap,

Можно задать something-src *.domain.com, что покроет все подмножество поддоменов известного нам домена

Можно. Только ещё и сам домен надо указать, поскольку *.domain.com не разрешает сам domain.com.
Делайте как вам удобнее, только на публичных доменах типа github.com открывать *.github.com не комильфо.

И есть нюансы - 'self' немного шире чем простое указание *.domain.com domain.com. В браузерах с поддержкой CSP3 'self' разрешает схемы ws: /wss: (вебсокеты).

<img style="something"> можно, согласно одному лишь default-src domain.com

Нельзя, для инлайн-стилей в теге требуется 'unsafe-inline' в директиве style-src.
А на яваскрипте через HTMLElement.style - установить стиль можно, CSP это не запрещает.

Логику можно посмотреть в вебархиве, поскольку на сайте Мозиллы это убрали 5 лет назад. Покликайте на оранжевенькие 'Example', увидите что защищает и от каких от каких типов атак.

Уж если злоумышленник может модифицировать наш HTML-файл, то ему фиолетово, как именно XSSить.

Весь фикус-пикус, что Content Security Policy не даст ему активно XSS-ить, даже в случае модификации HTML-кода. Потому, что до HTTP-заголовка добраться и подменить его не так просто.
А 'unsafe-unline' как раз и нехорошо разрешать, тк скрипт из неразрешённого хост-источника получает контроль над HTML. Браузер не может различить, какую секцию <script>...</script> вставил вембастер, а какую - вредоносы. Поэтому, либо все скрипты из внешних файлов, либо - подписывайте их по 'nonce-value'

[ifap]

granty,

Делайте как вам удобнее, только на публичных доменах типа github.com открывать *.github.com не комильфо

То есть, необходимости нет, есть "вкусовщина" и отдельные случаи, когда имя хоста заранее неизвестно целиком и приходится использовать 'self' (попутно убивая смысл применения CSP)?

Нельзя, для инлайн-стилей в теге требуется 'unsafe-inline'

Значит я слишком буквалистски прочел мозилловское:

Allows the use of inline resources, such as inline <script> elements, javascript: URLs, inline event handlers, and inline <style> elements.

;) Тогда вопрос снимается и логика понятна.

А 'unsafe-unline' как раз и нехорошо разрешать, тк скрипт из неразрешённого хост-источника получает контроль над HTML.

Ваши бы слова - да разрабам, например, движка phpBB в уши...