Для каких типов контента следует устанавливать заголовки HTTP-ответов, связанных с безопасностью?

Я создал веб-приложение (на моем любимом языке Fantom!) И блокирую его от XSS и других подобных атак, предоставляя стандартные заголовки HTTP-ответов.

У меня вопрос, для каких ответов должны быть установлены заголовки?

Я мог бы установить заголовки для каждого ответа, но это кажется довольно расточительным, учитывая, что большинство запросов будет для изображений, шрифтов, таблиц стилей и т. Д. Content-Security-Policy в частности может стать довольно продолжительным.

Поскольку многие заголовки относятся к HTML-странице-владельцу (и Javascript, содержащемуся в ней), я чувствую, что большинство из них нужно устанавливать только для HTML-страниц.

Я посмотрел на различные ресурсы, такие как:

И хотя они объясняют, что делают заголовки, они не объясняют, для каких ресурсов они должны использоваться и обслуживаться!

Я сделал список ниже заголовков ответа HTTP и для которых Content-Types Я думаю, что они должны быть обслужены. Но кто-нибудь знает, правильно ли это?

HTTP Response Header       text/html  All Content-Types
-------------------------  ---------  -----------------
Content-Security-Policy        X
Referrer-Policy                               X
Strict-Transport-Security                     X
X-Content-Type-Options                        X
X-Frame-Options                X
X-XSS-Protection               X

(Когда я сказал text/html Я также включаю application/xhtml+xml .)

Referrer-Policy это все типы контента из-за возможности CSS загружать шрифты и изображения.

Источник

1 ответ

Решение

Теоретически, это нужно только "активным" документам, так же как и заголовок X-XSS-Protection ( соответствующий ответ здесь от Info Security). Пока политика установлена ​​в основном документе (даже через метатег), внешние ресурсы должны быть заблокированы на основе этой политики, а не политики на внешнем ресурсе (это легко увидеть при загрузке файлов CDN, которые почти наверняка не имеют ваш CSP, или любой CSP, установлен).

Поэтому я бы сказал, что ваша оценка верна; Текст /HTML и XML обязательно должны иметь все, что может выполнять Javascript. Это не должно иметь значения для статических ресурсов. Они будут заблокированы или разрешены на основе CSP основного документа.

Я признаю, что лично я просто отправляю их на все ресурсы, обслуживаемые непосредственно с моего сервера, так как я скорее буду параноиком, чем что-то испортит, и несколько десятков байт на запрос не окажут большого влияния, особенно на сайт, который не не обслуживать много запросов. И если ваш сайт обслуживает огромное количество запросов... обычно лучше сократить количество запросов, прежде чем пытаться сократить заголовки.

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

Источник

Strict-Transport-Security

В рекомендациях по развертыванию "Списка предварительной загрузки HSTS" указано:

Добавить Strict-Transport-Security заголовок ко всем ответам HTTPS

В Apache это будет выглядеть так (заметьте, я не включил preload Директива, разработчики должны прочитать рекомендации по развертыванию списка предварительной загрузки HSTS, прежде чем добавлять это):

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=16070400; includeSubDomains" "expr=%{HTTPS} == 'on'"
</IfModule>


X-XSS-Protection

Если вы используете CSP (без разрешения 'unsafe-inline') тогда вам, вероятно, не нужно беспокоиться о X-XSS-Protection больше:


Content-Security-Policy (и связанные с безопасностью заголовки в целом)

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

  • HTML
  • XML
  • JS (Javascript выполняется только в "контексте просмотра", однако это применимо из-за способности JS создавать Workers, см. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)
  • PDF - Да, действительно, файлы PDF также могут выполнять JavaScript.


Кроме того, ИМО рассмотреть возможность установления строгого Referrer-Policy для ВСЕХ ответов. Надеюсь, это поможет:)

Источник
Другие вопросы по тегам