Рекомендации по использованию заголовков Referer и Referrer-Policy

Maud Nalpas

В этой статье приведены рекомендации по настройке Referrer-Policy и использованию реферера во входящих запросах.

Сводка

• Неожиданная утечка информации из разных источников нарушает конфиденциальность пользователей интернета. В этом случае может помочь правило для URL перехода.
• Рекомендуем задать правило для URL перехода strict-origin-when-cross-origin. Это позволяет сохранить большую часть полезных функций реферера, снижая при этом риск утечки данных из разных источников.
• Не используйте рефереры для защиты от подделки межсайтовых запросов (CSRF). Вместо этого используйте токены CSRF и другие заголовки в качестве дополнительного уровня защиты.

Основы Referer и Referrer-Policy

HTTP-запросы могут содержать необязательный заголовок Referer, в котором указывается источник или URL веб-страницы, откуда был отправлен запрос. Заголовок Referrer-Policy определяет, какие данные будут доступны в заголовке Referer.

В примере ниже заголовок Referer содержит полный URL страницы на сайте site-one, с которой был отправлен запрос.

Заголовок Referer может присутствовать в запросах разных типов:

• Запросы навигации, когда пользователь нажимает на ссылку.
• Запросы дополнительных ресурсов, когда браузер запрашивает изображения, окна iframe, скрипты и другие ресурсы, необходимые для работы страницы.

Для навигации и элементов iframe вы также можете получить доступ к этим данным с помощью JavaScript, используя document.referrer.

Значения Referer могут дать вам много полезной информации. Например, сервис аналитики может использовать их, чтобы определить, что 50% посетителей сайта site-two.example пришли с сайта social-network.example. Однако если полный URL, включая путь и строку запроса, отправляется в заголовке Referer между источниками, это может поставить под угрозу конфиденциальность пользователя и создать риски для безопасности.

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

URL 6 – это URL функции. Если письмо получит кто-то другой, злоумышленник сможет получить контроль над аккаунтом пользователя.

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

Какие правила доступны и чем они отличаются?

Вы можете выбрать одно из восьми правил. В зависимости от правил данные, доступные из заголовка Referer (и document.referrer), могут быть следующими:

• Нет данных (заголовок Referer отсутствует).
• Только источник
• Полный URL: источник, путь и строка запроса.

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

В таблице ниже показано, как правила в отношении реферера ограничивают данные URL, доступные из заголовка Referer и document.referrer.

Полный список правил и примеры их работы можно найти на сайте MDN.

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

• Все правила, учитывающие схему (HTTPS или HTTP), например strict-origin, no-referrer-when-downgrade и strict-origin-when-cross-origin, обрабатывают запросы от одного источника HTTP к другому так же, как и запросы от одного источника HTTPS к другому, несмотря на то что HTTP менее безопасен. Это связано с тем, что для этих правил важно, происходит ли понижение уровня безопасности, то есть может ли запрос раскрыть данные из зашифрованного источника незашифрованному, как в случае с запросами HTTPS → HTTP. Запрос HTTP → HTTP полностью не зашифрован, поэтому понижения уровня не происходит.
• Если запрос одноисточниковый, это означает, что схема (HTTPS или HTTP) одинакова, поэтому уровень безопасности не снижается.

Правила в отношении рефереров, используемые в браузерах по умолчанию

По данным на октябрь 2021 г.

Если правило в отношении рефереров не задано, браузер использует правило по умолчанию.

Рекомендации по настройке правил в отношении заголовка Referrer

Правила в отношении URL перехода можно задать разными способами:

• В заголовке HTTP
• В коде HTML
• из JavaScript для каждого запроса;

Для разных страниц, запросов или элементов можно задать разные правила.

HTTP-заголовок и метаэлемент относятся к уровню страницы. Приоритет правил определяется следующим образом:

1. Правила на уровне элементов
2. Правила на уровне страницы
3. Как в браузере по умолчанию

Пример

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

Изображение запрашивается с правилом no-referrer-when-downgrade, а все остальные запросы дополнительных ресурсов с этой страницы следуют правилу strict-origin-when-cross-origin.

Как посмотреть правила в отношении URL перехода?

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

Вы также можете использовать инструменты разработчика в Chrome, Edge или Firefox, чтобы посмотреть правила в отношении заголовка Referrer, используемые для определенного запроса. На момент написания этой статьи Safari не показывает заголовок Referrer-Policy, но показывает отправленный заголовок Referer.

Какое правило следует задать для сайта?

Мы настоятельно рекомендуем явно задать правила, повышающие конфиденциальность, например strict-origin-when-cross-origin (или более строгие).

Почему "явно"?

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

• В разных браузерах по умолчанию используются разные правила, поэтому, если вы полагаетесь на настройки браузера, ваш сайт не будет работать предсказуемо во всех браузерах.
• Браузеры внедряют более строгие настройки по умолчанию, такие как strict-origin-when-cross-origin, и механизмы, такие как обрезка URL перехода для запросов из разных источников. Если вы явно выберете правила, повышающие конфиденциальность, до того, как изменятся настройки браузера по умолчанию, вы сможете контролировать ситуацию и проводить тестирование по своему усмотрению.

Почему strict-origin-when-cross-origin (или более строгая)?

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

• Безопасность. Если ваш сайт использует протокол HTTPS (если нет, рекомендуем перейти на него), вы не захотите, чтобы URL вашего сайта передавались в HTTP-запросах, не использующих HTTPS. Поскольку эти данные видны всем пользователям сети, их утечка может привести к атакам типа "человек посередине". Правила no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer и strict-origin решают эту проблему.
• Повышение конфиденциальности. При междоменном запросе no-referrer-when-downgrade передает полный URL, что может привести к проблемам с конфиденциальностью. strict-origin-when-cross-origin и strict-origin передают только источник, а no-referrer не передает ничего. В результате у вас остаются следующие варианты: strict-origin-when-cross-origin, strict-origin и no-referrer.
• Полезно. no-referrer и strict-origin никогда не передают полный URL, даже для запросов из одного источника. Если вам нужен полный URL, лучше использовать strict-origin-when-cross-origin.

Поэтому strict-origin-when-cross-origin – это разумный выбор.

Пример. Настройка правила strict-origin-when-cross-origin

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

или на стороне сервера, например в Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Что делать, если strict-origin-when-cross-origin (или более строгие правила) не подходит для всех ваших сценариев использования?

В этом случае используйте прогрессивный подход: задайте для сайта строгие правила, например strict-origin-when-cross-origin, а для отдельных запросов или элементов HTML – более мягкие.

Пример правила на уровне элемента

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari/WebKit может ограничивать document.referrer или заголовок Referer для межсайтовых запросов. Подробнее…

Пример: правило на уровне запроса

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

Что ещё нужно учитывать?

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

Рекомендации по работе с входящими запросами

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

Защита пользовательских данных

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

Входящие рефереры могут меняться {referer-can-change}

Использование URL перехода из входящих междоменных запросов имеет несколько ограничений:

• Если вы не можете контролировать реализацию отправителя запроса, то не можете делать предположения о заголовке Referer (и document.referrer), который вы получаете. Отправитель запроса может в любой момент перейти на правила no-referrer или более строгие правила , чем использовались ранее. Это означает, что вы получаете меньше данных от Referer, чем раньше.
• Браузеры все чаще используют правило Referrer-Policy strict-origin-when-cross-origin по умолчанию. Это означает, что теперь во входящих междоменных запросах вы можете получать только источник, а не полный URL перехода, если на сайте отправителя не заданы правила.
• Браузеры могут изменить способ управления Referer. Например, некоторые разработчики браузеров могут решить всегда сокращать рефереры до источников в запросах подресурсов из разных источников, чтобы защитить конфиденциальность пользователей.
• Заголовок Referer (и document.referrer) может содержать больше данных, чем вам нужно. Например, он может содержать полный URL, когда вам нужно только знать, является ли запрос перекрестным.

Альтернативы Referer

Вам может потребоваться рассмотреть альтернативные варианты, если:

• Важная функция вашего сайта использует URL перехода входящих межсайтовых запросов.
• Ваш сайт больше не получает часть URL перехода, которая ему нужна в перекрестном запросе. Это происходит, когда отправитель запроса меняет свои правила или когда у него нет правил и меняются правила браузера по умолчанию (как в Chrome 85).

Чтобы определить альтернативные варианты, сначала проанализируйте, какую часть URL перехода вы используете.

Если вам нужен только источник

• Если вы используете реферер в скрипте, у которого есть доступ к странице верхнего уровня, то можете использовать window.location.origin.
• Если доступны заголовки Origin и Sec-Fetch-Site, они могут содержать нужную вам информацию, например Origin или сведения о том, является ли запрос перекрестным.

Если вам нужны другие элементы URL (путь, параметры запроса и т. д.)

• Параметры запроса могут соответствовать вашему варианту использования, что избавит вас от необходимости анализировать реферер.
• Если вы используете реферер в скрипте, у которого есть доступ к странице верхнего уровня, то в качестве альтернативы можно использовать window.location.pathname. Извлеките только часть пути URL и передайте ее в качестве аргумента, чтобы не передавать потенциально конфиденциальную информацию в параметрах URL.

Если вы не можете использовать эти альтернативы:

• Проверьте, можно ли изменить ваши системы так, чтобы отправитель запроса (например, site-one.example) явно указывал нужную вам информацию в конфигурации.
  • Преимущества: более явный, лучше защищает конфиденциальность пользователей site-one.example, более перспективный.
  • Минус: потенциально больше работы для вас или пользователей вашей системы.
• Проверьте, можно ли настроить на сайте, который отправляет запросы, правило для URL перехода no-referrer-when-downgrade для каждого элемента или запроса.
  • Минус: потенциально менее конфиденциально для пользователей site-one.example, может не поддерживаться в некоторых браузерах.

Защита от подделки межсайтовых запросов (CSRF)

Отправитель запроса может не передавать URL перехода, задав правило no-referrer, а злоумышленник может даже подделать этот URL.

Используйте токены CSRF в качестве основного средства защиты. Для дополнительной защиты используйте SameSite, а вместо Referer – заголовки, такие как Origin (доступен в запросах POST и CORS) и Sec-Fetch-Site (если доступен).

Ведение журналов и отладка

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

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

Платежи

Поставщики платежных услуг могут использовать заголовок Referer входящих запросов для проверок безопасности.

Пример:

• Пользователь нажимает кнопку Купить на сайте online-shop.example/cart/checkout.
• online-shop.example перенаправляет пользователя на сайт payment-provider.example для управления транзакцией.
• payment-provider.example сравнивает Referer этого запроса со списком разрешенных значений Referer, заданных продавцами. Если совпадений не найдено, payment-provider.example отклоняет запрос. Если совпадение есть, пользователь может перейти к транзакции.

Рекомендации по проверке безопасности платежей

Поставщики платежных услуг могут использовать Referer для базовой защиты от некоторых атак. Однако заголовок Referer сам по себе не является надежной основой для проверки. Сайт, запрашивающий платеж, может установить правило no-referrer, которое делает информацию Referer недоступной для поставщика платежных услуг.

Проверка Referer может помочь поставщикам платежных услуг выявить неопытных злоумышленников, которые не настроили правила no-referrer. Если вы используете Referer в качестве первой проверки:

• Не рассчитывайте, что Referer всегда будет доступен. Если он есть, проверьте его на соответствие минимальному набору данных, который он может содержать, то есть источнику.
  • При настройке списка разрешенных значений Referer указывайте только источник, без пути.
  • Например, допустимым значением атрибута Referer для online-shop.example будет online-shop.example, а не online-shop.example/cart/checkout. Если вы не ожидаете получить Referer или ожидаете получить значение Referer, которое является только источником запрашивающего сайта, вы предотвращаете ошибки, которые могут возникнуть из-за предположений о Referrer-Policy продавца.
• Если заголовок Referer отсутствует или присутствует и базовая проверка источника Referer прошла успешно, вы можете перейти к другому, более надежному методу проверки.

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

Что происходит с Referer, когда сайт продавца, использующий протокол HTTP и не имеющий правил в отношении заголовка Referrer, перенаправляет пользователя на сайт поставщика платежных услуг, использующий протокол HTTPS?

В запросе к поставщику платежных услуг, использующему HTTPS, не будет видно Referer, потому что большинство браузеров по умолчанию используют strict-origin-when-cross-origin или no-referrer-when-downgrade, если на сайте не заданы правила. Переход Chrome на новые правила по умолчанию не повлияет на это поведение.

Заключение

Правила в отношении источника запроса – отличный способ обеспечить конфиденциальность пользователей.

Чтобы узнать больше о различных методах защиты пользователей, ознакомьтесь с нашей подборкой Безопасность и защита.

Ресурсы

• Что такое "один сайт" и "один источник"
• Новый заголовок безопасности: Referrer-Policy (2017)
• Referrer-Policy на MDN
• Заголовок Referer: вопросы конфиденциальности и безопасности на MDN
• Изменение в Chrome: намерение Blink реализовать
• Изменение в Chrome: намерение Blink поставлять
• Изменение в Chrome: запись о статусе
• Изменения в Chrome: запись в блоге о бета-версии 85
• Обсуждение на GitHub: как разные браузеры обрезают заголовок Referrer
• Спецификация Referrer-Policy

Благодарим всех, кто помогал нам и оставлял отзывы, особенно Каустубху Говинда (Kaustubha Govind), Дэвида Ван Клива (David Van Cleve), Майка Веста (Mike West), Сэма Даттона (Sam Dutton), Роуэна Меревуда (Rowan Merewood), Jxck и Кейси Баскес (Kayce Basques).