Comments 35
видимо заголовок нужен для IE8 чтобы принимать cookies третьих лиц.

Да, именно для этого однажды его использовал.
Благодарю, очень познавательно!
Интересно, а есть возможность внедрять на серверы антивирусы, и каждый сайт таким образом может быть в доверенной зоне для пользователя (например логотип антивируса внизу страницы, означающий, что текущий сайт безопасен)
Смысл конечно же не в логотипе. Функциональность его очевидно будет в том, что он будет кликабельным — и приведёт в список доверенных сайтов по версии какого-нибудь антивирусного пакета «Dr.Internet». Далее суть остаётся в следующей выжимке: существует некий антивирусный пакет, который устанавливается на сеервер и работает со всем прочим софтом. Он круглосуточно занимается мониторингом кода на сервере, и при обнаружении опасности действует типично для антивируса. Для пользователя же данная система будет неким залогом надёжности сайта. Таким образом — хостер становится клиентом, покупающим софт у разработчика антивируса, а разработчик антивируса лицензирует данный сервер. Пользователи сайта же больше привлекаются к лицензированным сайтам.
Когда, я читаю идеи некоторых людей в постах — мне интересно поучаствовать в их развитии, почему бы нет, зачем сразу кидаться, что это не работает :)
И что в этих заголовках экзотического? Они есть на многих сайтах.
Думаю было бы не плохо в конце статьи собрать в список все рассмотренные запросы и рекомендуемые для них значения. А статья информативная получилась, жаль кармы не хватает для того чтобы плюсануть её.
Всё зависит от ресурса, какие требования и ограничения на нём должны быть. Для большинства сайтов хватит и одного:
Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'; frame-ancestors 'none'
С Content-Encoding и с сжатием, поддерживаемым браузером, который можно узнать, прочитав заголовок запроса Accept-Encoding

Если планируется, что сайт должен быть вставлен как фрейм или допустим embed, то frame-ancestors 'none' нужно исключить.

А если используется https, то тут нужен обязательно Strict-Transport-Security и желательно Public-Key-Pins

PKP это, вообще, плохая идея для "желательно". С PKP можно достаточно легко накосячить так что вы навсегда потеряете домен. Я бы советовал очень хорошо перед этим подумать, и потестить конфигурацию где-то вдалеке от продакшена.

Большинство сайтов перестанут нормально работать без unsafe-inline в script-src, а с ним CSP теряет 99% профита. Но это сложная тема.
думаю, загрузка одного изображения больше нагрузит браузер, чем все перечисленные заголовки вместе взятые. К тому же когда речь идёт о безопасности, как правило, ресурсов не жалеют.
UFO landed and left these words here
Непонятен смысл Public-Key-Pins. Если уж злоумышленник заставил пользователя занести свой сертификат в доверенные, что ему мешает после этого устроить MitM, изменяя в отдаваемых пользователю страницах этот заголовок на отпечаток своего сертификата, или вообще их выкидывая? Или это от чего-то другого защищает?

От недобросовестных или недостаточно защищённых удостоверяющих центров, которые могут без вашего ведома выпустить и выдать легитимный сертификат для вашего домена третьему лицу. Причём, если недобросовестный УЦ не поддерживает Certificate Transparency, то других механизмов, кроме HPKP с включённым репортингом, узнать о беде нет.

Новые сертификаты и заголовки будут приняты браузером только после истечения max-age старых

про Strict-Transport-Security


А если потребуется переключиться на HTTP перед сроком истечения max-age или если установлен preload? Не получится. Этот заголовок требует строгого соблюдения. Поэтому в этом случае пользователю придётся очистить историю и настройки.

Это ложь, если вам, как владельцу сайта, необходимо перейти на http, это делается очень просто: выставлением HSTS max-age=0 и редирект на http версию.
как-то так это выглядит в диалекте nginx


    listen 443 ssl;
    location / {
        rewrite ^ http://$host$uri redirect;
        add_header              Strict-Transport-Security   "max-age=0";
}
Это интересно. А прув есть? Просто автор утверждает обратное.

Ну например, https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/. Однако, нужно понимать, что для отключения нужно передать этот заголовок в рамках нормально работающего https-сеанса, поэтому невозможно резко отключить HSTS, когда какой-то факап уже случился. Т.е. невозможно быстренько сделать вид, что никакого HSTS небыло, если забыл вовремя обновить обновить сертификат: нужно получать и устанавливать на сайт новый, и только с полностью работающим HTTPS можно будет, если всё ещё нужно, выставить max-age=0.

Да, действительно, спасибо за ссылку. Вот еще и в RFC то же написано.
> если в исходном коде есть нечто похожее на запросы, то это может оказаться угрозой.

Лучше, думаю, не переводить вообще, чем переводить вот так. У вас вообще не объяснено как это работает и что это делает.
За что купил, за то и продаю. Или вы хотите чтобы автор в одно предложение объяснил каким образом браузер находит XSS?
if you find a part of the request in the source code, it might be an attack.

В оригинале идёт речь про конкретный запрос, почему у вас "запросы" во множественном числе?

Да, хочу. Иначе зачем эта статья нужна? Это не какая-то эвристика или нейронная сеть, определяющая «угрозу», это очень простой алгоритм.

Если в исходном коде страницы встречается аргумент из query string или path запроса без экранирования, то такая страница считается успешно атакованной XSS и не отображается пользователю.
По-моему, это просто перевод, наверное, неплохой статьи. Требовать от переводчика разъяснений отдельных предложений было бы, скажем так, нежелательно.
Я вроде требую от переводчика точного перевода.

Было:
if you find a part of the request in the source code

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

Или вы считаете это достаточно точным?

дело не в том, что вы требуете, а где вы требуете — об этом в личку пишут

По поводу Public-Key-Pins вы не очень хорошие примеры привели. facebook отдает только public-key-pins-report-only. Надо было смотреть что он в консоль вываливает при поддельных сертификатах. А google вообще никаких PKP в заголовках не отдает. Вот все и пропускается, видимо, с левыми сертификатами в локальных хранилищах.

github, например, отдаёт HPKP:


Public-Key-Pins: max-age=5184000; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="RRM1dGqnDFsCJXBTHky16vi1obOlCgFFn/yOhI/y+ho="; pin-sha256="k2v657xBsOVe1PQRwOsHsw3bsGT2VzIqz5K+59sNQws="; pin-sha256="K87oWBWM9UZfyddvDfoxL+8lpNyoUB2ptGtn0fv6G2Q="; pin-sha256="IQBnNBEiFuhj+8x6X8XLgh01V9Ic5/V3IRQLNFFc7v4="; pin-sha256="iie1VXtL7HzAMF+/PVPR9xzT80kQxdZeJ+zduCB3uj0="; pin-sha256="LvRiGEjRqfzurezaWuj8Wie2gyHMrW5Q06LspMnox7A="; includeSubDomains
Тут выше поднимался вопрос про SEO. Вспомнил про заголовок X-Robots-Tag который по идее должен работать аналогично robots.txt
Only those users with full accounts are able to leave comments. Log in, please.