php referrer policy strict origin when cross origin

Referrer-Policy

The Referrer-Policy HTTP header controls how much referrer information (sent via 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 entirely. No referrer information is sent along with requests.

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 when performing a same-origin request to the same protocol level. Send origin (only) for cross origin requests and requests to less secure destinations.

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

Send the origin (only) 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 :

Источник

Нужные HTTP-заголовки

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

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

Домашняя работа

В интернете есть несколько сервисов, которые проанализируют ваш сайт и посоветуют, какие заголовки добавить. Я посмотрел securityheaders.io и Observatory от Mozilla, чтобы дополнить собственные знания и данные, полученные из сети Fastly.

Какие заголовки должны быть на вашем сайте

Итак, какие основные заголовки должны быть в ответах ваших серверов? Бóльшая часть отвечает за повышение безопасности:

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

Referrer-Policy. Настраивает уровень детализации для включения в заголовок Referer при уходе со страницы. Помогает предотвратить утечку данных на сайты, куда идут ссылки. Настоятельно рекомендуется.

Strict-Transport-Security. Предотвращает любые попытки подключения к сайту по обычному HTTP. Помогает остановить MiTM-атаки и повышает безопасность сайта. Тоже настоятельно рекомендуется.

CORS. Заголовки Cross-Origin Resource Sharing позволяют загружать URL скриптом с другого источника. Это необязательный заголовок. Заголовки такого типа являются разрешающими, а не запрещающими, поэтому их отсутствие даёт максимальный уровень безопасности.

Другие предназначены для производительности:

Timing-Allow-Origin. Даёт инструментам мониторинга доступ к данным по таймингу запроса. Это во многом отношении ценная информация, она позволяет сильно улучшить качество аналитики вроде Google Analytics или Speedcurve.

Link rel=preload. Сообщает браузеру о критических ресурсах, которые следует скачать, даже если непосредственной необходимости в них ещё не возникло. Используйте заголовок для шрифтов и важных CSS.

Server-Timing. Предоставляет с сервера информацию по таймингу, которая дополняет Navigation Timing API и Resource Timing API более детальной информацией о времени выполнения задач на сервере (например, «сколько времени мы провели в MySQL»). Отлично подходит для мониторинга данных о производительности, в сочетании с инструментами RUM Beacon.

Давайте более подробно рассмотрим некоторые из них.

Content Security Policy: держите его в рамках

Хотя Content-Security-Policy — один из самых важных заголовков, он также один из самых многословных. Самый большой заголовок CSP, который я нашёл в HTTPArchive, занимал 10 КБ. Десять килобайт. Для одного значения заголовка. Хуже того: в то время как тела ответов могут передаваться потоком, заголовки буферизуются большинством серверов и прокси-серверов и передаются только после завершения. Сжатие HTTP/2 немного помогает запоминать их между запросами, но это не означает, что заголовок 10 КБ — это нормально.

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

Referrer-Policy

Можете выбрать несколько стратегий из доступных вариантов Referrer-Policy, но мой обычный совет — это “origin-when-cross-origin”, который включает Referer для всех нормальных запросов, но усекает значение только до домена, если ссылка идёт от одного домена к другому. Ссылки в пределах вашего собственного сайта включают полный реферер.

Измерение Server-Timing на edge-сервере CDN

У Server-Timing есть много приятных особенностей, а одна из них в том, что в ответ можете добавить несколько экземпляров — и все они объединятся в браузере или инструменте RUM. То есть если запрос проходит через несколько этапов серверной обработки — как это происходит в CDN — каждый этап добавляет собственные метрики времени, и они не конфликтуют между собой. Вот как добавить метрики Fastly в заголовок с помощью VCL в конфигурации службы Fastly:

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

Метрики времени сервера доступны через объект performance в JavaScript и отображаются в сетевой панели Chrome Devtools:

В настоящее время визуализация показателей на рудиментарном уровне. Но над этим усиленно работают, так что в будущем пользовательский интерфейс, вероятно, значительно улучшится.

Добавляем все правильные заголовки

Fastly — хорошее место для добавления всех заголовков безопасности и производительности. Ниже показано, как они выглядит все вместе. Добавьте этот код на этапе доставки (deliver) потока запросов, изменив значения на те, которые подходят для вашего сайта (постарайтесь не копипастить без проверки, что значения подходят для вашего сайта):

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

Источник

Fetch API

Давайте рассмотрим оставшуюся часть API, чтобы охватить все возможности.

Нижеследующий список – это все возможные опции для fetch с соответствующими значениями по умолчанию (в комментариях указаны альтернативные значения):

Довольно-таки внушительный список, не так ли?

Опция signal разъяснена в главе в Fetch: прерывание запроса.

Теперь давайте пройдёмся по оставшимся возможностям.

referrer, referrerPolicy

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

Опция referrer позволяет установить любой Referer в пределах текущего источника или же убрать его.

Для того, чтобы установить другой URL-адрес (должен быть с текущего источника):

Выделяется 3 типа запросов:

Вот таблица со всеми комбинациями:

Допустим, у нас есть админка со структурой URL, которая не должна стать известной снаружи сайта.

Если мы хотим, чтобы другие сайты получали только источник, но не URL-путь, это сделает такая настройка:

Опция mode – это защита от нечаянной отправки запроса на другой источник:

Эта опция может пригодиться, если URL-адрес для fetch приходит от третьей стороны, и нам нужен своего рода «глобальный выключатель» для запросов на другие источники.

credentials

Опция credentials указывает, должен ли fetch отправлять куки и авторизационные заголовки HTTP вместе с запросом.

cache

Настройка cache позволяет игнорировать HTTP-кеш или же настроить его использование:

redirect

Обычно fetch прозрачно следует HTTP-редиректам, таким как 301, 302 и так далее.

Это можно поменять при помощи опции redirect :

integrity

Опция integrity позволяет проверить, соответствует ли ответ известной заранее контрольной сумме.

Как описано в спецификации, поддерживаемыми хеш-функциями являются SHA-256, SHA-384 и SHA-512. В зависимости от браузера, могут быть и другие.

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

Мы можем добавить это в настройку integrity вот так:

Затем fetch самостоятельно вычислит SHA-256 и сравнит его с нашей строкой. В случае несоответствия будет ошибка.

keepalive

Опция keepalive указывает на то, что запрос может «пережить» страницу, которая его отправила.

Например, мы собираем статистические данные о том, как посетитель ведёт себя на нашей странице (на что он кликает, части страницы, которые он просматривает), для анализа и улучшения интерфейса.

Когда посетитель покидает нашу страницу – мы хотим сохранить собранные данные на нашем сервере.

Для этого мы можем использовать событие window.onunload :

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

У неё есть ряд ограничений:

Источник

пятница, 27 июля 2018 г.

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

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

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

Также статью можно прочитать в конфлюенсе — там есть оглавление и таблички отображаются лучше, чем в блоггере.

Request Headers:. Host: scotthelme.co.ukReferer: https://twitter.com/Scott_Helme/status/760790725776830464Upgrade-Insecure-Requests: 1.

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

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

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

Referrer Policy — это HTTP response header, заголовок ответа. Он может содержать одно из следующих значений:

enum ReferrerPolicy <
«»,
«no-referrer»,
«no-referrer-when-downgrade»,
«same-origin»,
«origin»,
«strict-origin»,
«origin-when-cross-origin»,
«strict-origin-when-cross-origin»,
«unsafe-url»
>;

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

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

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, с любого сайта.

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

Источник

Cross-Origin Resource Sharing (CORS)

Cross-Origin Resource Sharing (CORS) — механизм, использующий дополнительные HTTP-заголовки, чтобы дать возможность агенту пользователя получать разрешения на доступ к выбранным ресурсам с сервера на источнике (домене), отличном от того, что сайт использует в данный момент. Говорят, что агент пользователя делает запрос с другого источника (cross-origin HTTP request), если источник текущего документа отличается от запрашиваемого ресурса доменом, протоколом или портом.

В целях безопасности браузеры ограничивают cross-origin запросы, инициируемые скриптами. Например, XMLHttpRequest и Fetch API следуют политике одного источника (same-origin policy). Это значит, что web-приложения, использующие такие API, могут запрашивать HTTP-ресурсы только с того домена, с которого были загружены, пока не будут использованы CORS-заголовки.

Механизм CORS поддерживает кросс-доменные запросы и передачу данных между браузером и web-серверами по защищённому соединению. Современные браузеры используют CORS в API-контейнерах, таких как XMLHttpRequest или Fetch, чтобы снизить риски, присущие запросам с других источников.

Кто должен читать данную статью?

Конкретнее, эта статья для web-администраторов, разработчиков серверной стороны и front-end разработчиков. Современные браузеры поддерживают клиентские компоненты cross-origin обмена, включая заголовки и соблюдение правил политики. Но этот новый стандарт означает, что сервера также должны поддерживать новые заголовки запросов и ответов. Другая статья для разработчиков серверной части, описывающая перспективы cross-origin обмена на стороне сервера (с примерами кода на PHP), к дополнительному прочтению.

Какие запросы используют CORS?

Этот стандарт cross-origin обмена используется для разрешения кросс-сайтовых HTTP запросов для:

Эта статья описывает общие понятия Cross-Origin Resource Sharing и включает обсуждение необходимых HTTP заголовков.

Обзор функциональности

Стандарт Cross-Origin Resource Sharing работает с помощью добавления новых HTTP-заголовков, которые позволяют серверам описывать набор источников, которым разрешено читать информацию, запрашиваемую web-браузером. В частности, для методов HTTP-запросов, которые могут привести к побочным эффектам над данными сервера (в частности, для HTTP методов, отличных от GET или для POST запросов, использующих определённые MIME-типы), спецификация требует, чтобы браузеры «предпроверяли» запрос, запрашивая поддерживающие методы с сервера с помощью метода HTTP-запроса OPTIONS и затем, поверх «подтверждения» с сервера, отсылали фактический запрос с фактическим методом HTTP-запроса. Сервера также могут оповещать клиентов должны ли «полномочия» (включая Cookies и HTTP Authentication данные) быть отправлены с запросом.

Следующая секция описывает сценарии, а также предоставляет анализ использования HTTP-заголовков.

Примеры сценариев управления доступом

Обсуждение Cross-Origin Resource Sharing с точки зрения сервера (включая фрагменты кода на PHP) может быть найдено в статье Server-Side Access Control (CORS).

Простые запросы

Некоторые запросы не заставляют срабатывать CORS preflight. Они называются “простыми запросами” в данной статье, хотя Fetch спецификация, определяющая CORS, не использует этот термин. Запрос, для которого не срабатывает CORS preflight— так называемый “простой запросы”—это запрос, удовлетворяющий следующим условиям:

Это приведёт к простому обмену запросами между клиентом и сервером, используя CORS заголовки для обработки привилегий:

Посмотрим, что браузер отправит в таком случае на сервер, а также проверим ответ сервера:

Отметьте, никакой домен, кроме http://foo.example (определён ORIGIN: заголовок в запросе, как в 10 строке выше), не может получить доступ к ресурсу кросс-сайтовым способом. Заголовок Access-Control-Allow-Origin должен содержать значение, которое было отправлено в заголовке Origin запроса.

Предварительные запросы

В отличии от “простых запросов” (обсуждено выше), «предварительные» запросы сначала отправляют HTTP-запрос методом OPTIONS к ресурсу на другом домене, чтобы определить, является ли фактический запрос безопасным для отправки. Кросс-сайтовые запросы предварительно просматриваются таким образом, так как они могут быть причастны к пользовательским данным.

В частности, запрос предварительно просматривается, если выполняется любое из следующих условий:

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

Замечание: как описано ниже, фактический POST запрос не включает Access-Control-Request-* заголовки; они нужны только для OPTIONS запроса.

Как только предварительный запрос завершён, отправляется настоящий запрос:

Предварительные запросы и переадресации

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

Запрос был перенаправлен на ‘https://example.com/foo’, который запрещён для запросов из разных источников, требующих предварительной проверки

Запрос требует предварительной проверки, которая запрещена для перенаправления между источниками

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

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

Но если невозможно внести эти изменения, то возможен другой способ:

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

Запросы с учётными данными

В этом примере контент, изначально загруженный из http://foo.example, выполняет простой GET запрос к ресурсу http://bar.other, который устанавливает файлы cookie. Содержимое на foo.example может содержать такой JavaScript:

Вот пример обмена между клиентом и сервером:

Запросы с учётными данными и wildcards

В процессе ответа на запрос с учётными данными сервер обязан указать точный источник в поле заголовка Access-Control-Allow-Origin вместо спецсимвола » * «.

Отметьте, что заголовок ответа Set-Cookie в примере выше также устанавливает дополнительные куки. В случае неудачи, возникает исключение, в зависимости от используемого API.

Заголовки HTTP ответов

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

Access-Control-Allow-Origin

Access-Control-Allow-Origin определяет либо один источник, что указывает браузеру разрешить этому источнику доступ к ресурсу; либо — для запросов без учётных данных — значение » * «, которое говорит браузеру разрешить запросы из любых источников.

Например, чтобы разрешить http://mozilla.org доступ к ресурсу, можно указать:

Если сервер возвращает название хоста, вместо «*», также может быть указан заголовок Vary со значением Origin, чтобы показать клиентам, что ответы с сервера будут отличаться в зависимости от значения заголовка запроса Origin.

Access-Control-Expose-Headers

The Access-Control-Expose-Headers (en-US) header lets a server whitelist headers that browsers are allowed to access. For example:

This allows the X-My-Custom-Header and X-Another-Custom-Header headers to be exposed to the browser.

Access-Control-Max-Age

The Access-Control-Max-Age header indicates how long the results of a preflight request can be cached. For an example of a preflight request, see the above examples.

The delta-seconds parameter indicates the number of seconds the results can be cached.

Access-Control-Allow-Credentials

The Access-Control-Allow-Credentials (en-US) header Indicates whether or not the response to the request can be exposed when the credentials flag is true. When used as part of a response to a preflight request, this indicates whether or not the actual request can be made using credentials. Note that simple GET requests are not preflighted, and so if a request is made for a resource with credentials, if this header is not returned with the resource, the response is ignored by the browser and not returned to web content.

Access-Control-Allow-Methods

The Access-Control-Allow-Methods header specifies the method or methods allowed when accessing the resource. This is used in response to a preflight request. The conditions under which a request is preflighted are discussed above.

An example of a preflight request is given above, including an example which sends this header to the browser.

Access-Control-Allow-Headers

The Access-Control-Allow-Headers header is used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.

The HTTP request headers

This section lists headers that clients may use when issuing HTTP requests in order to make use of the cross-origin sharing feature. Note that these headers are set for you when making invocations to servers. Developers using cross-site XMLHttpRequest capability do not have to set any cross-origin sharing request headers programmatically.

Origin

The Origin header indicates the origin of the cross-site access request or preflight request.

The origin is a URI indicating the server from which the request initiated. It does not include any path information, but only the server name.

Note that in any access control request, the Origin header is always sent.

Access-Control-Request-Method

The Access-Control-Request-Method (en-US) is used when issuing a preflight request to let the server know what HTTP method will be used when the actual request is made.

Examples of this usage can be found above.

Access-Control-Request-Headers

The Access-Control-Request-Headers (en-US) header is used when issuing a preflight request to let the server know what HTTP headers will be used when the actual request is made.

Источник