Referrer policy что это

Referrer-Policy

The Referrer-Policy HTTP header controls how much referrer information (sent with the Referer header) should be included with requests. Aside from the HTTP header, you can set this policy in HTML.

Syntax

Note: The original header name Referer is a misspelling of the word «referrer». The Referrer-Policy header does not share this misspelling.

Directives

The Referer header will be omitted: sent requests do not include any referrer information.

Send the origin, path, and querystring in Referer when the protocol security level stays the same or improves (HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS). Don’t send the Referer header for requests to less secure destinations (HTTPS→HTTP, HTTPS→file).

Send the origin, path, and query string for same-origin requests. Don’t send the Referer header for cross-origin requests.

Send only the origin when the protocol security level stays the same (HTTPS→HTTPS). Don’t send the Referer header to less secure destinations (HTTPS→HTTP).

Send the origin, path, and querystring when performing a same-origin request. For cross-origin requests send the origin (only) when the protocol security level stays same (HTTPS→HTTPS). Don’t send the Referer header to less secure destinations (HTTPS→HTTP).

Send the origin, path, and query string when performing any request, regardless of security.

Warning: This policy will leak potentially-private information from HTTPS resource URLs to insecure origins. Carefully consider the impact of this setting.

Integration with HTML

You can also set referrer policies inside HTML. For example, you can set the referrer policy for the entire document with a element with a name of referrer :

Источник

Полезный META тег Referrer Policy для HTTPS сайта.

Самые популярные товары с Али по лучшей цене здесь

Полезный META тег Referrer Policy для HTTPS сайта.

Не очень понятно, зачем и кому именно выгодна концепция тотального перевода сайтов на https протокол. Но похоже, поезд уже ушёл, и поделать с этим ничего нельзя.

Поисковые гиганты уровня Гугла откровенно лоббируют https протокол документов в своей поисковой выдаче. Браузеры в адресной строке стебутся и глумятся, как могут, над «небезопасными» сайтами. В SEO нише все новости подряд про преференции сайтов под SSL сертификатами, и так далее.

И добро бы, будь это просто новостной фон.
Прочли и забыли.

Но на деле наши хостеры уже давно и всем подряд выдают SSL-сертификаты типа DV (domain validation), причём насильно. Пусть самого начального уровня (бесплатные), и на короткий срок, но автоматически продлеваемые. А это уже не досужие разговоры, и с этим следует как-то определиться.

Наблюдения за Гуглом.

Никто не предполагал, что далее случится странное.

Местный автор заметил, что спустя некоторое время индексирующий бот Гугла, обходя его сайт, видел на странице авторизации все ссылки в навигации в протоколе https (в соответствии с логикой, указанной выше PHP оператором, все внутренние ссылки строятся относительно морды сайта, заданной вот так), и последовательно заменял в выдаче у всех этих документов в URL-е протокол на безопасный.

Понятно, что произошло дальше.

Заходя впоследствии на «безопасные» версии этих документов, индексирующий бот получал все внутренние ссылки с них тоже исключительно в https протоколе, и спустя краткое время в поисковой выдаче практически не осталось http документов. Ну разве что редиректы всякие, ведущие наружу.

А вот это уже знак. Наверное, надо теперь подвергнуть легалайзу действия Гугла, и полностью отказаться от http версии сайта в пользу https. Тем паче, что переиндексация фактически уже случилась, причём естественным образом, исключительно с помощью индексирующего бота (местный автор, конечно же, не занимается ахинеей типа построение карты сайта и тому подобными извращениями).

Кстати, Яндекс ничего подобного делать не стал, и по запросу «site:lasto.com» выдавал документы строго в http протоколе. При этом никакой директивы Host в файле роботса прописано не было, в Яндекс.Вебмастере местный автор никогда даже не регистрировался, и зеркало сайта или предпочтительный протокол в нём не настраивал.

Перевод сайта на HTTPS протокол.

Поскольку всякий вебмастер приучен сразу и правильно понимать намёки великого Гугла, который из каких-то соображений однозначно выбрал «правильный» протокол, было бы логично теперь избавиться от одной из версий ресурса в пользу другой. Что делается явной записью в конфиге вместо «странного» PHP оператора:

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

А теперь неприятное. Недостатки HTTPS протокола.

Замедление загрузки сайта.

Нужно быть готовым к тому, что «обычный» трафик ходит заметно быстрее, чем «защищённый». Ибо во втором случае есть дополнительное обращение к третьей стороне (поставщик SSL сертификата), что занимает лишнее время перед тем, как сайт начнёт загружаться. И эта задержка заметна на глаз.

Ошибка SSL: Потеря доступа к сайту.

Есть определённая вероятность того, что бесплатные начальные сертификаты (обычно от «Let’s Encrypt»), выпускаемые всего на три месяца, могут быть не продлены вовремя. В результате сайт не открывается, на экране ошибка доступа по причине недействительности SSL сертификата. Что печалит.

Отзыв SSL сертификата, Роскомнадзор.

Как мы теперь все прекрасно понимаем, не очень-то вменяемый Роскомнадзор вполне может в любой момент заблокировать любую подсеть IP адресов любой ёмкости, причём по любой надуманной причине. Если в тех айпишниках вдруг окажется инфраструктура удостоверяющего центра, все сайты с SSL сертификатом от него тут же отваливаются, и больше ничего не показывают.

Такое уже разок было (Роскомнадзор заблокировал Comodo, а заодно и себя, ибо сам в тот момент имел SSL сертификат от Comodo). И много раз ещё повторится в разных вариантах.

Причём ситуация намного хуже, чем может показаться.

Сайты под «безопасным» протоколом по факту более централизованы, чем их дикие собратья. Ибо сертификат сайта может быть легко отозван (правда, по решению суда).

Но легче и проще ни в какой суд вообще не обращаться, а выпустить (и навязать его всем пользователям) какой-нибудь «Яндекс-браузер», который, как и любой другой браузер, тоже имеет право отзывать SSL сертификат как отдельного сайта, так и вообще все сертификаты, выпущенные любым удостоверяющим центром.

Наличие у сайта SSL сертификата искажает статистику исходящего с него трафика. Вот тут будьте внимательны.

Все мы помним, как Гугл поломал детектирование поисковых запросов, просто переведя свой поиск на https протокол. Ибо наши сайты в большинстве своём тогда были «беззащитные», а им по уставу не положено видеть параметры в URL-ах ссылающегося на них сайта. А именно в тех параметрах прописан поисковый запрос.

Самый последний пункт нам, как вебмастерам, очень интересен. И, видимо, настала пора познакомиться с такой сущностью, как Referrer Policy. Собственно, это и является истинной темой нашей сегодняшней встречи.

МЕТА тег «Referrer Policy»

Это относительно свеженький стандарт, от 2017 года. Но уже популярный.
На языке первоисточника доступен тут.

Встраивается в сайт простейшим образом, в виде тега секции header

meta name = «referrer» content = «*» >

Вместо звёздочки можно и нужно писать разные сущности, и в зависимости от вписанной сущности внешний сайт, на который ссылается страница с таким вот МЕТА тегом в коде, либо будет знать в точности источник трафика, либо только его домен, либо не узнает вообще ничего.

Понимая, что при этом как ссылающийся сайт, так и получающий трафик по ссылке, могут работать в любом из протоколов (http или https), мы получим множество вариантов, которые стоит изучать в отдельности.

no-referrer

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

Это, конечно, эпический фейл и фиаско. Если уж скрипт системы тикетов написан идиотом, хотя бы добавьте данный МЕТА-тег на все страницы тикетов в указанном выше виде. Что, конечно, совсем не поможет, если браузер клиента старый, и этот тег не разумеет.

no-referrer-when-downgrade

Реферер не передаётся от https к http сайту, и передаётся во всех остальных случаях. Причём это справедливо и для варианта общения сайта с самим собой, но в разных протоколах.

С большой степенью вероятности отсутствие данного МЕТА-тега вообще приведёт к такому же эффекту.

same-origin

Очень интересный вариант, когда реферер передаётся только внутри собственного сайта, при переходе между его документами. Но только в случае, когда этот сайт работает по https протоколу. В любом другом случае реферера просто нет.

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

origin

На какой бы сайт не ссылалась страница с таким тегом, в качестве реферера будет виден лишь домен сайта. Документ в URL-е не передаётся. Протокол принимающего трафик сайта безразличен.

strict-origin

То же самое, но уже играет роль иерархия протоколов. При переходе с https сайта на http (в том числе и в пределах одного домена) реферер не передаётся. Во всех остальных случаях в качестве реферера фигурирует морда сайта, а не его конкретный документ.

origin-when-cross-origin

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

То же самое, что и четвёртый вариант, но тут метрика должна быть работоспособна.

strict-origin-when-cross-origin

unsafe-url

Реферер передаётся в любом случае.

Конечно, это ненормальная ситуация.

Поэтому всё-таки имеет смысл вписать в шаблон дизайна сайта МЕТА-тег в самом последнем варианте его написания. Чтобы любой сайт имел возможность наблюдать в своей статистике все ссылающиеся на него ресурсы в рамках максимально демократичной процедуры «unsafe-url Referrer Policy».

Примечание.

Естественно, реферер (информация об источнике трафика) переносится от сайта к сайту силами браузера посетителя, и браузер либо знаком с «Referrer Policy», либо не понимает, чего от него хочет хитрый МЕТА-тег.

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

Рекомендации.

Как видим, МЕТА-тег «Referrer Policy» хоть и не отличается разнообразием вариантов (их номенклатуру можно было бы и расширить), тем не менее позволяет работать с реферерами по-разному, в зависимости от протокола сайта. Это ценное свойство, особенно если можно открыть сайт хоть «безопасно», хоть «не безопасно».

Правда, если сервисы написаны по уму (например, URL всех страниц сервиса одинаковый, ибо данные передаются исключительно через POST, а GET параметры не используются вообще), тегу особо и нечего защищать. Разве что сам факт наличия исходящей ссылки.

Тем не менее, тег однозначно полезный, знать про него надо.
Как и вовсю пользоваться им.

Другие статьи категории «Вебмастеру на заметку»

Видимо, случилось прекращение роста в доменной зоне RU.

Какие элементы сайта сегодня можно потерять.

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

№ 1 Referrer Policy применительно к движку местного автора.

Стоит знать, что так называемая Нана при передаче любой информации посредством форм, построенных на фреймворке движка, обязательно контролирует источник данных. Тот самый реферер.

Если вдруг окажется, что он не определён, или не совпадает с ожидаемым, форма тупо не сработает. Да ещё и будет ругаться.

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

Зато определённый интерес представляет политика «same-origin»

Под ней сайт будет принимать данные только в том случае, если он открыт в https протоколе, то есть когда взаимодействие с пользователем или админом происходит под шифрованием, безопасным образом. А в ином случае данные не примутся.

№ 2 Директива Хост для Яндекса не нужна

20 марта сего года Яндекс в блоге для вебмастеров сообщил, что отказывается от директивы «Host» в пользу 301 редиректа, и разрешил удалить её из роботс. Так окончились пятнадцать лет борьбы со спецификацией.

Спасибо за информацию.
Даже и не знал 🙂

Воистину, всё, что «хочет от тебя странного», должно быть проигнорировано просто на автомате.

Источник

Заголовок сообщения Referrer Policy

Это перевод статьи «A new security header: Referrer Policy» Scott Helme, публикуется с разрешения автора. ©

Чтобы получить скриншот как на картинке:

Это небольшое вступление от меня, а дальше уже текст автора. Свои вставки буду выделять курсивом.

Заголовок Referrer Policy позволяет сайту контролировать значение заголовка Referer для ссылок, ведущих с вашей страницы.

Что такое Referer?

Когда пользователь переходит с одного сайта на другой, второй сайт сохраняет информацию «откуда ко мне пришли». Благодаря этому мы получаем всякие метрики типа Яндекс.Метрики или Google Analytics. И именно благодаря этой информации мы узнаем, откуда к нам приходит трафик. Вот, например, Скотт точно знает, что к нему на сайт за неделю 4000 человек пришло именно из Твиттера. Это видно из заголовка Referer:

А вот так выглядит трафик в моем блоге за неделю. И эта информация также собирается из заголовка Referer:

Заголовок Referer позволяет понять, откуда к нам пришли пользователи, и это очень удобная фича. Особенно для маркетинга — стоит ли оплачивать рекламу в ФБ, ВК, Яндексе? Это недешево стоит, а оценить выхлоп можно благодаря заголовку. Вложились в рекламу и следим, сколько покупателей пришло в магазин. Так и делаем выводы, окупилась реклама или это деньги «в никуда».

Но бывают случаи, когда мы не хотим показывать информацию в этом заголовке. Или контролировать то, что там отображается. И вот как раз для этого нужен заголовок Referrer Policy.

Заголовок Referrer Policy

Официальная информация по заголовку опубликована 26 января 2017 года, найти ее можно на сайте W3C Candidate Recommendation. Но автор решил вынести ее в свой блог, а я — в свой. Так удобнее, когда ты сам контролируешь свои статьи и не зависишь от сломавшихся ссылок. А еще у Скотта описание более понятное благодаря примерам. Именно поэтому я перевожу его статью, а не официальную документацию.

Ниже я объясню каждый вариант, что именно он делает.

пустая строка

no-referrer

Значение no-referrer говорит браузеру никогда не слать заголовок referer для запросов с твоего сайта. Это касается как ссылок на внешние ресурсы, так и на другие страницы своего сайта. Полная анонимность.

Если вы не видите отличий между ссылками, то обратите внимание на разницу HTTP и HTTPS. Автор показывает, что нет разницы, переходим мы с защищенного ресурса или нет. В других значениях заголовка эта разница будет

no-referrer-when-downgrade

Браузер НЕ будет отправлять значение referer при переходе с HTTPS на HTTP, но отправит полную ссылку при переходе с HTTP куда-то еще.

Тут не важно, отличаются ли source и destination, или ведут на один и тот же сайт (кросс-ссылки внутри сайта)

same-origin

Браузер отправляет значение referer только в том случае, если ссылка ведет на тот же сайт. В любом другом случае значение будет пустое

origin

Браузер всегда отображает в referer только сайт, откуда пришел запрос. Всю дополнительную информацию из URL он вырезает

strict-origin

Аналогично origin, но данный заголовок запрещает слать информацию на HTTP, только на защищенные ссылки: HTTPS

origin-when-cross-origin

Браузер отправляет полный URL на тот же сайт, и неполный (только название) на все остальные

strict-origin-when-cross-origin

unsafe-url

Браузер всегда посылает полный URL, с любого сайта.

Рекомендации

Источник

Как усилить защищенность веб-приложений при помощи HTTP заголовков

Как мы видели в предыдущих частях этой серии, серверы могут отправлять заголовки HTTP, чтобы предоставить клиенту дополнительные метаданные в ответе, помимо отправки содержимого, запрошенного клиентом. Затем клиентам разрешается указывать, каким образом следует читать, кэшировать или защищать определенный ресурс.

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

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

HTTP Strict Transport Security (HSTS)

С конца 2012 года сторонникам “HTTPS Everywhere” стало проще заставить клиента всегда использовать безопасную версию протокола HTTP благодаря Strict Transport Security: очень простая строка Strict-Transport-Security: max-age=3600 скажет браузеру что в течение следующего часа (3600 секунд) он не должен взаимодействовать с приложением по небезопасным протоколам.

Вам может быть интересно узнать, что происходит, когда пользователь посещает ваш сайт в первый раз, поскольку заранее не определена политика HSTS: злоумышленники потенциально могут обмануть пользователя по версии http:// вашего сайта и провести там атаку, так что еще есть место для проблем. Это серьезная проблема, поскольку HSTS — это механизм доверия при первом использовании. Он пытается убедиться, что после посещения веб-сайта браузер знает, что при последующем взаимодействии должен использоваться HTTPS.

Обойти этот недостаток можно было бы путем поддержки огромной базы данных веб-сайтов, поддерживающих HSTS, что Chrome делает через hstspreload.org. Сначала вы должны установить свою политику, а затем посетить веб-сайт и проверить, может ли он быть добавлен в базу данных. Например, мы можем видеть, что Facebook входит в список.

Отправляя свой веб-сайт в этот список, вы можете заранее сообщить браузерам, что ваш сайт использует HSTS, так что даже первое взаимодействие между клиентами и вашим сервером будет осуществляться по безопасному каналу. Но это обходится дорого, так как вам действительно нужно принять участие в HSTS. Если, по какой-либо причине, вы хотите, чтобы ваш веб-сайт был удален из списка, это непростая задача для поставщиков браузеров:

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

Домены могут быть удалены, но для того, чтобы донести до пользователей обновление Chrome, требуются месяцы, и мы не можем дать гарантии относительно других браузеров. Не запрашивайте включение в список, если вы не уверены, что сможете поддерживать HTTPS для всего своего сайта и всех его поддоменов в течение длительного времени.
— Источник: https://hstspreload.org/

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

HTTP Public Key Pinning (HPKP)

HTTP Public Key Pinning — это механизм, который позволяет нам сообщать браузеру, какие SSL-сертификаты следует ожидать при подключении к нашим серверам. Это заголовок использует механизм доверия при первом использовании, как и HSTS, и означает, что после подключения клиента к нашему серверу он будет хранить информацию о сертификате для последующих взаимодействий. Если в какой-то момент клиент обнаружит, что сервер использует другой сертификат, он вежливо откажется подключиться, что очень затруднит проведение атак типа «человек посередине» (MITM).

Вот как выглядит политика HPKP:

Заголовок объявляет, какие сертификаты сервер будет использовать (в данном случае это два из них), используя хэш сертификатов, и включает дополнительную информацию, такую ​​как время жизни этой директивы ( max-age = 3600 ) и несколько других деталей. К сожалению, нет смысла копать глубже, чтобы понять, что мы можем сделать с закреплением открытого ключа, поскольку Chrome не одобряет эту функцию — сигнал о том, что его принятие обречено на провал.

В результате этих потенциально катастрофических последствий принятие HPKP было чрезвычайно низким, и были случаи, когда крупные веб-сайты были недоступны из-за неправильной конфигурации. Учитывая все вышесказанное, Chrome решил, что пользователям будет лучше без защиты, предлагаемой HPKP, и исследователи в области безопасности не совсем против этого решения.

Expect-CT

Инициатива по обеспечению прозрачности сертификатов — это усилия, предпринимаемые Google для обеспечения:

Открытой платформы для мониторинга и аудита SSL-сертификатов практически в реальном времени.

В частности, прозрачность сертификатов позволяет обнаруживать сертификаты SSL, которые были ошибочно выданы центром сертификации или злонамеренно получены от другого безупречного центра сертификации. Это также позволяет идентифицировать центры сертификации, которые пошли на мошенничество и злонамеренно выдают сертификаты.
— Источник: https://www.certificate-transparency.org/

Заголовок принимает эту форму:

В этом примере сервер просит браузер:

X-Frame-Options

Представьте, что вы видите веб-страницу, подобную этой

Как только вы нажимаете на ссылку, вы понимаете, что все деньги на вашем банковском счете исчезли. Что случилось?

Вы были жертвой атаки clickjacking.

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

Пример довольно экстремальный, но он должен дать вам понять, какие могут быть последствия атаки с помощью кликджеккинга. Пользователь намеревается нажать на конкретную ссылку, в то время как браузер вызовет щелчок по «невидимой» странице, которая была встроена в виде фрейма.

К счастью, браузеры придумали простое решение этой проблемы: X-Frame-Options (XFO), который позволяет вам решить, можно ли встроить ваше приложение в виде iframe на внешних веб-сайтах. Популяризированная Internet Explorer’ом 8, XFO был впервые представлен в 2009 году и до сих пор поддерживается всеми основными браузерами.

Это работает так: когда браузер видит iframe, он загружает его и проверяет, что его XFO позволяет включить его в текущую страницу перед его рендерингом.

XFO считался лучшим способом предотвращения атак с использованием щелчков на основе фреймов до тех пор, пока через несколько лет не вступил в игру еще один заголовок — Content Security Policy или CSP для краткости.

Content Security Policy (CSP)

Чтобы понять, как CSP помогает нам, сначала нужно подумать о векторе атаки. Допустим, мы только что создали наш собственный поисковик Google, где есть простое поле для ввода с кнопкой отправки.

Это веб-приложение не делает ничего волшебного. Оно просто,

Удивительно! Наше приложение невероятно поняло наш поиск и нашло похожее изображение. Если мы углубимся в исходный код, доступный по адресу github.com/odino/wasec/tree/master/xss, мы скоро поймем, что приложение представляет проблему безопасности, поскольку любое ключевое слово, которое ищет пользователь, напрямую печатается в HTML:

Это представляет неприятное следствие. Злоумышленник может создать определенную ссылку, которая выполняет произвольный JavaScript в браузере жертвы.

Если у вас есть время и терпение, чтобы запустить пример локально, вы сможете быстро понять всю мощь CSP. Я добавил параметр строки запроса, который включает CSP, поэтому мы можем попробовать перейти к вредоносному URL-адресу с включенным CSP:

Как вы видите в приведенном выше примере, мы сказали браузеру, что наша политика CSP допускает только сценарии, включенные из того же источника текущего URL, что мы можем легко проверить, обратившись к URL с помощью curl и просмотрев заголовок ответа:

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

Они могли бы украсть все пользовательские куки, которые могут содержать очень конфиденциальные данные (подробнее об этом в следующей статье).

К настоящему времени должно быть ясно, как CSP помогает нам предотвращать ряд атак на веб-приложения. Вы определяете политику, и браузер будет строго придерживаться ее, отказываясь запускать ресурсы, которые будут нарушать политику.

Отчеты позволят вам понять, какие критические изменения могут быть вызваны политикой CSP, которую вы хотели бы развернуть, и исправить их соответствующим образом. Мы даже можем указать URL-адрес отчета, и браузер отправит нам отчет. Вот полный пример политики только для отчетов:

Политики CSP сами по себе могут быть немного сложными, например, в следующем примере:

Эта политика определяет следующие правила:

Для получения дополнительной информации о CSP я бы порекомендовал developer.mozilla.org/en-US/docs/Web/HTTP/CSP.

X-XSS-Protection

Несмотря на то, что он заменен CSP, заголовок X-XSS-Protection обеспечивает аналогичный тип защиты. Этот заголовок используется для смягчения атак XSS в старых браузерах, которые не полностью поддерживают CSP. Этот заголовок не поддерживается Firefox.

Его синтаксис очень похож на то, что мы только что видели:

Еще более интересным является поведение по умолчанию в Chrome, когда на веб-странице не указана политика CSP или XSS. Сценарий, который мы можем проверить, добавив параметр xss=off в наш URL ( http://localhost:7888/?search=%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E&xss=off ):

Удивительно, но Chrome достаточно осторожен, чтобы не допустить рендеринга страницы, что затрудняет создание отраженного XSS. Впечатляет, как далеко зашли браузеры.

Feature policy

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

Если у нас есть все сомнения, то как эта политика влияет на API браузера, мы можем просто проанализировать ее:

X-Content-Type-Options

Иногда умные функции браузера в конечном итоге наносят нам вред с точки зрения безопасности. Ярким примером является MIME-сниффинг, методика, популярная в Internet Explorer.

Cross-Origin Resource Sharing (CORS)

Однако в некоторых случаях может потребоваться выполнение запросов AJAX между разными источниками, и именно по этой причине браузеры реализовали Cross Origin Resource Sharing (CORS), набор директив, позволяющих выполнять запросы между доменами.

Механизм, лежащий в основе CORS, довольно сложен, и мы не будем практично рассматривать всю спецификацию, поэтому я сосредоточусь на «урезанной» версии CORS.

Все, что вам нужно знать на данный момент, это то, что с помощью заголовка Access-Control-Allow-Origin ваше приложение сообщает браузеру, то, что можно получать запросы из других источников.

Если мы посмотрим на пример по адресу github.com/odino/wasec/tree/master/cors, мы увидим, как браузер предотвращает доступ к ресурсу из другого источника. Я настроил пример, чтобы сделать запрос AJAX от test-cors к test-cors-2 и вывести результат операции в браузере. Когда сервер test-cors-2 получает указание использовать CORS, страница работает так, как вы ожидаете. Попробуйте перейти на http://cors-test:7888/?cors=on

Но когда мы удаляем параметр cors из URL, браузер вмешивается и запрещает нам доступ к содержимому ответа:

Важный аспект, который нам нужно понять, заключается в том, что браузер выполнил запрос, но не позволил клиенту получить к нему доступ. Это чрезвычайно важно, так как это все еще оставляет нас уязвимыми, если наш запрос вызвал бы любой побочный эффект на сервере. Представьте, например, что наш банк разрешил бы перевод денег, просто вызвав ссылку my-bank.com/transfer?amount=1000&from=me&to=attacker. Это было бы катастрофой!

Это говорит нам пару вещей:

Я завершу свой обзор этой функции здесь, но, если вы заинтересованы в глубоком понимании CORS, у MDN есть очень длинная статья, которая блестяще охватывает всю спецификацию на developer.mozilla.org/en-US/docs/Web/HTTP/CORS.

X-Permitted-Cross-Domain-Policies

Сильно связанные с CORS, X-Permitted-Cross-Domain-Policies нацелены на междоменные политики для продуктов Adobe (а именно, Flash и Acrobat).

Я не буду вдаваться в подробности, так как это заголовок, предназначенный для очень конкретных случаев использования. Короче говоря, продукты Adobe обрабатывают междоменный запрос через файл crossdomain.xml в корневом каталоге домена, на который нацелен запрос, и X-Permitted-Cross-Domain-Policies определяет политики для доступа к этому файлу.

Звучит сложно? Я бы просто предложил добавить X-Permitted-Cross-Domain-Policies: none и игнорировать клиентов, желающих делать междоменные запросы с помощью Flash.

Referrer-Policy

Хорошо, может быть, это был не каждый из нас. Но я чертовски уверен, что сделал эту ошибку тогда. Доверие заголовку Referer для предоставления нам достоверной информации о происхождении пользователя. Заголовок был действительно полезным, пока мы не решили, что отправка этой информации на сайты может представлять потенциальную угрозу для конфиденциальности наших пользователей.

Вот некоторые из наиболее распространенных значений, которые может принимать Referrer-Policy :

Тестирование вашей безопасности

Я хочу завершить эту статью ссылкой на securityheaders.com, невероятно полезный веб-сайт, который позволяет вам убедиться, что в вашем веб-приложении установлены правильные заголовки, связанные с безопасностью. После того, как вы отправите URL, вам будет передана оценка и разбивка заголовок за заголовком. Вот пример отчета для facebook.com:

Если вы сомневаетесь в том, с чего начать, securityheaders.com — отличное место, чтобы получить первую оценку.

HTTP с контролем состояния: управление сеансами с файлами cookie

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

В следующем посте мы углубимся в одну из самых неправильно понятых функций протокола HTTP: куки.

Рожденные для того, чтобы привести какое-либо состояние в HTTP без сохранения состояния, куки, вероятно, используются (и использовались) каждым из нас для поддержки сеансов в наших веб-приложениях: когда бы ни было какое-либо состояние, которое мы хотели бы сохранить, оно всегда Легко сказать «сохранить его в печенье». Как мы увидим, файлы cookie не всегда являются самыми безопасными из хранилищ, и к ним следует относиться осторожно при работе с конфиденциальной информацией.

Источник