Изменить реферер в браузере

Обновлено: 06.07.2024

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

Получается, что я наврал вам, дорогие читатели, конечно, не намеренно.

Рисунок 1. Я был не прав!

Оказалось, что вы можете установить заголовок Referer с помощью JavaScript с помощью простого трюка, о котором я не знал в то время.

Но давайте сделаем резервную копию на секунду. Что это за заголовок Referer и почему я продолжаю писать его с ошибками?

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

И Referer написан с ошибкой, потому что он написан с ошибкой в самом RFC в 1996 году — это совершенно не моя вина. Давайте посмотрим, как это выглядит на практике.

Рисунок 2. Нажатие ссылки на архив

Рисунок 3. Реферер установлен на главную страницу

Теперь, когда мы находимся на странице архива, если мы перейдем по ссылке на этой странице, наш Referer будет установлен на страницу архива.

Рисунок 4. О нажатии на недавнюю публикацию

И после того, как мы нажали на публикацию Кто носил это лучше всего?, мы видим, что в запросе в качестве Реферера указана страница Архива.

Рисунок 5. Реферер настроен на страницу архива

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

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

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

Рисунок 6. Форма нового пользователя находится на странице user-new.php

Рисунок 7. POST для создания нового администратора

Мы можем сделать такой же запрос из нашего вредоносного кода JavaScript, чтобы добавить нового администратора; однако Referer будет установлен целевым браузером как страница, на которую мы смогли внедрить наш вредоносный код JavaScript. Функцию JavaScript, которую мы собираемся использовать в нашей полезной нагрузке для добавления нового администратора, можно увидеть на рисунке ниже:

Рисунок 8. Пример вредоносных данных для добавления нового администратора

Когда этот JavaScript запускается в браузере нашей цели, делается запрос на добавление нового пользователя-администратора с паролем, который известен нам (злоумышленнику). В этом примере наш вредоносный JavaScript загружается со страницы предварительного просмотра сообщения в блоге, где конкретная уязвимость XSS, которую мы используем, помещает нашу полезную нагрузку. Это приводит к следующему запросу, где Referer установлен на страницу предварительного просмотра публикации, а не на страницу нового пользователя, как в реальном запросе.

Рисунок 9. Подозрительное реферальное значение поступает не с той страницы

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

Рисунок 10. Различные значения Referer

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

Как же нам получить контроль над заголовком Referer в JavaScript? Мы могли бы попытаться установить заголовок в нашем JavaScript, добавив следующий код:

Рисунок 11. Попытка установить заголовок Referer

Но браузер не позволит нам это сделать:

Рисунок 12. Браузер не разрешает устанавливать Referer

Можно попытаться напрямую установить window.document.referrer, но это тоже не работает.

Рисунок 13. Большое спасибо, современный браузер

К счастью, это делает невероятно простой трюк:

Рисунок 14. Изменение записей истории

Результатом изменения записи истории перед отправкой запроса является измененное значение Referer:

Рисунок 15. Реферер имеет значение False

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

Рисунок 16. Изменение видимого URL

Особо наблюдательный пользователь может заметить необычное поведение страницы. К счастью для нас, JavaScript чертовски быстр. Мы можем легко использовать запись истории, чтобы изменить URL-адрес, сделать вредоносный запрос, а затем изменить URL-адрес обратно, прежде чем пользователь заметит.

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

Рисунок 17. Печать соответствующих значений URL

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

Рисунок 18. Нам нужно сохранить путь и значения поиска

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

Рисунок 19 – Переключение значения реферера

Рисунок 20. Значение фальшивого реферера

И URL переключается обратно мгновенно, прежде чем пользователь заметит:

Рисунок 21. URL-адрес восстановлен

Это простой метод управления значением Referer из JavaScript. Это не будет полезно часто. Немногие приложения проверяют значение Referer в рамках контроля безопасности, но они существуют. Еще менее распространенным способом применения этого трюка является приложение, которое отражает значение Referer (например, ссылку «назад»), потенциально открывая дверь для уязвимости XSS.

Это часто легко продемонстрировать с помощью Burp Repeater, вручную установив значение Referer с помощью полезной нагрузки JavaScript. Однако практическая эксплуатация маловероятна, так как все современные браузеры будут кодировать URL-адрес значения Referer перед его отправкой, нарушая полезную нагрузку XSS, SQLi и т. д. Если вы обнаружите приложение, которое отражает заголовок Referer и по какой-то необъяснимой причине также декодирует URL-адрес значения Referer, у вас будет уязвимость отраженного XSS, которую можно использовать.

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

Точная информация, которая отправляется в заголовке Referrer в запросе с вашего сайта, определяется установленным вами заголовком Referrer-Policy.

Referrer-Policy и Referer.

Если политика не задана, используется браузер по умолчанию. Веб-сайты часто используют настройки браузера по умолчанию.

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

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

Chrome планирует переключить свою политику по умолчанию с no-referrer-when-downgrade на strict-origin-when-cross-origin начиная с версии 85.

Это означает, что если для вашего веб-сайта не задана политика, Chrome по умолчанию будет использовать strict-origin-when-cross-origin. Обратите внимание, что вы по-прежнему можете установить политику по своему выбору; это изменение повлияет только на веб-сайты, для которых не задана политика.

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

strict-origin-when-cross-origin обеспечивает большую конфиденциальность. В соответствии с этой политикой в заголовке Referer запросов между источниками отправляется только источник.

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

Отправленный реферер (и document.referrer) для запроса между источниками, в зависимости от политики.

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

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

Chrome планирует начать развертывание новой политики реферера по умолчанию в версии 85 (июль 2020 г. для бета-версии, август 2020 г. для стабильной версии). См. статус в записи статуса Chrome.

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

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

Теперь вы можете проверить, как работает ваш веб-сайт и серверная часть.

Еще один способ обнаружить влияние — проверить, использует ли кодовая база вашего веб-сайта реферер — либо через заголовок Referer входящих запросов на сервере, либо из document.referrer в JavaScript.

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

Если вы используете реферер для доступа к полному пути или строке запроса для запросов к вашему сайту, у вас есть несколько вариантов:

Используйте альтернативные методы и заголовки, такие как Origin и Sec-fetch-Site, для защиты от CSRF, ведения журнала и других вариантов использования. Ознакомьтесь с Referer и Referrer-Policy: лучшие практики.
Вы можете согласовать с партнерами определенную политику, если это необходимо и прозрачно для ваших пользователей. Контроль доступа — когда реферер используется веб-сайтами для предоставления определенного доступа к своим ресурсам другим источникам — может быть таким случаем, хотя с изменением Chrome источник по-прежнему будет совместно использоваться в заголовке Referer (и в document.referrer ).< /li>

Обратите внимание, что большинство браузеров движутся в том же направлении, когда речь заходит о реферере (см. браузеры по умолчанию и их изменения в Referer и Referrer-Policy: лучшие практики).

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

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

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

Корпоративная политика Chrome ForceLegacyDefaultReferrerPolicy доступна для ИТ-администраторов, которые хотели бы принудительно использовать предыдущую политику реферера по умолчанию, запрещающую переход при переходе на более раннюю версию, в корпоративных средах. Это дает предприятиям дополнительное время для тестирования и обновления своих приложений.

Эта политика будет удалена в Chrome 88.

Есть ли у вас отзывы, которыми вы хотите поделиться, или о чем сообщить? Поделитесь своим мнением о намерении Chrome начать поставку или задайте свой вопрос в Твиттере на @maudnals.

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

Лучшие опыты по запросу ответа заголовка Referrer-Policy и использования реферера во входящих запросах.

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

Прежде чем мы начнем:

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

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

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

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

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

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

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

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

Вы можете установить следователя реферера.

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

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

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

По состоянию на июль 2020 г.

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

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

no-referrer-when-downgrade со strict-origin-when-cross-origin

Цель

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

Есть разные случаи установки политики реферера для вашего сайта:

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

Политика на уровне элементов.
Политика на уровне страницы.
Браузер по умолчанию.

Пример:

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

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

Chrome DevTools, панель Сеть с выбранным запросом.

Резюме: обнаружен поиск для получения конфиденциальности, например, strict-origin-when-cross-origin (или более строгую).

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

Политики по умолчанию либо no-referrer-when-downgrade , strict-origin-when-cross-origin , либо более строгиев зависимость от режима (конфиденциального просмотра или инкогнито). Таким образом, ваш сайт не будет вести себя предсказуемо в разных странах.
Браузеры принимают более строгие настройки по умолчанию, такие как strict-origin-when-cross-origin и такие механизмы, как обрезка реферера для исходников на другом источнике. Явный выбор политики опирается на стандартные настройки.

Все это означает, что strict-origin-when-cross-origin , как правило, является разумным выбором.

Пример: установка политики strict-origin-when-cross-origin

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

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

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

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

Предупреждение

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

Заголовок Referer может предоставить конфиденциальные, ценные или идентифицирующие данные, следовательно, вы уверены, что вы относитесь к какому-то к такому.

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

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

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

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

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

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

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

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

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

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

Обратите внимание на то, что отправитель запроса всегда может решить не отправлять реферера, установив отсутствие реферера (а присутствие может даже подделать реферера).

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

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

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

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

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

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

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

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

Какой метод проверки более надежен?

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

Защитная политика реферераотличный выбор ваших пользователей большей конфиденциальности.

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

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

Браузер Google Chrome — самый популярный веб-браузер. Его доля на рынке составляет более 70%. Какая бы новая политика ни применялась в Chrome, она повлияет на все веб-сайты, поскольку, скорее всего, большинство ваших посетителей тоже используют Chrome.

В Chrome 85, выпущенном в августе 2020 года, Google изменил политику реферера по умолчанию на "строгое происхождение при пересечении происхождения". Firefox внес такое же изменение в марте 2021 года в версию 87. Safari также следует той же политике.

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

TL;DR: как новая политика реферера Chrome влияет на вашу аналитику

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

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

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

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

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

Что такое политика реферера?

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

Это делается с помощью заголовка Referer (в нем отсутствует буква R из-за оригинальной орфографической ошибки). Заголовок Referer помогает серверу, на котором размещен ресурс, понять, какой веб-сайт запрашивает тот же ресурс.

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

Что делает новая политика реферера Chrome по умолчанию?

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

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

Это пример того, как выглядят рефералы, показанные с полным URL-адресом на панели управления Plausible Analytics:

< /p>

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

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

Каковы политики реферера по умолчанию в других браузерах?

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

Firefox использует strict-origin-when-cross-origin из версии 87. То же, что и Chrome.

Edge использует strict-origin-when-cross-origin из версии 85. То же, что и Chrome.

Safari использует строгое происхождение при перекрестном происхождении. То же, что и Chrome.

Brave использует no-referrer, при котором заголовок referrer полностью удален. Он никогда не использует полный URL-адрес даже для запросов из одного источника, и вы даже не можете видеть доменное имя для запросов из разных источников.

Проблема темного трафика

Как видите, не для каждого запроса из браузера будет указан реферер.

Возможно, вы знакомы с источником перехода "(прямой)/(нет)" в Google Analytics, с термином "теневой трафик" или с тем фактом, что общее количество посетителей редко совпадает с общим числом посетителей всех источников перехода вместе взятых.

Темный трафик охватывает весь трафик, по которому не передается реферер. Существует множество механизмов, при которых реферер не передается:

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

Реферер Facebook включает только тот факт, что посетитель пришел из Facebook. Facebook никогда не отправляет идентификатор поста или комментария, если кто-то нажал.

Twitter устанавливает реферер для своего средства сокращения ссылок, поэтому вы можете видеть укороченную ссылку, но не фактический твит, который привлек трафик. Компания Plausible Analytics делает все возможное, чтобы найти релевантный твит, с которого пришел посетитель, с помощью Twitter API.

Google не включает поисковые ключевые слова в реферер, поэтому вы можете видеть, что посетитель пришел из поиска Google, но вы не можете видеть, по какой ключевой фразе они вас нашли. В Plausible Analytics вы можете интегрировать данные Search Console, чтобы увидеть эти поисковые запросы.

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

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

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

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

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

Повышение важности пометки ссылок, которыми вы можете управлять

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

Чтобы свести к минимуму объем трафика, попадающего в категорию "без реферера", вы можете добавить к своим ссылкам специальные параметры запроса, такие как теги UTM.

Если в ссылке присутствует такой параметр запроса, как ?utm_source=, Plausible Analytics и большинство других инструментов аналитики будут отображать его как источник переходов. То же самое работает с параметрами запроса ref и source.

Привет! Мы Уку и Марко. Мы создаем легкую, ненавязчивую альтернативу Google Analytics. Вы можете прочитать о нашем путешествии и о том, что мы узнали на этом пути, в этом блоге.

Читайте также: