Лучшие практики реферальной политики и реферальной политики

Maud Nalpas

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

Краткое содержание

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

Реферер и реферальная политика 101

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-адреса с № 1 по № 5 содержат конфиденциальную информацию, а иногда и информацию, позволяющую установить личность. Незаметная утечка этой информации между источниками может поставить под угрозу конфиденциальность пользователей сети.

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

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

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

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

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

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

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

MDN предоставляет полный список правил и примеров поведения .

Вот несколько моментов, на которые следует обратить внимание при настройке политики рефереров:

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

Политика рефереров по умолчанию в браузерах

По состоянию на октябрь 2021 года

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

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

Существуют различные способы настройки правил перенаправления для вашего сайта:

• В качестве HTTP-заголовка
• В вашем HTML-коде
• JavaScript используется для каждого запроса отдельно.

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

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

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 .

Как ознакомиться с политикой рефереров?

Сайт securityheaders.com удобен для определения того, какую политику использует конкретный сайт или страница.

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

Какую политику следует установить для вашего веб-сайта?

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

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

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

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

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

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

• Безопасность : если ваш веб-сайт использует HTTPS ( если нет, сделайте это приоритетом ), вы не хотите, чтобы URL-адреса вашего сайта просачивались в запросах без 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}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Платежи

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

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

Что происходит с Referer , когда HTTP-сайт продавца без политики Referer перенаправляет на платежный провайдер HTTPS?

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

Заключение

Политика защиты рефереров — отличный способ обеспечить пользователям большую конфиденциальность.

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

Ресурсы

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

Выражаю огромную благодарность всем рецензентам за их вклад и отзывы, особенно Каустубхе Говинд, Дэвиду Ван Кливу, Майку Весту, Сэму Даттону, Роуэну Меревуду, Джеку и Кейси Баскес.