Как посмотреть referrer в браузере

Обновлено: 08.07.2024

Есть ли способ получить предыдущий URL в JavaScript? Что-то вроде этого:

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

Во многих случаях вы получите URL-адрес последней страницы, которую посетил пользователь, если он попал на текущую страницу, щелкнув ссылку (в отличие от ввода непосредственно в адресную строку, или, я полагаю, в некоторых случаях, отправив форму?). Указано DOM уровня 2. Подробнее здесь.

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

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

Это позволит перейти к ранее посещенному URL.

document.referrer соответствует вашим целям, но не работает для версий Internet Explorer более ранних, чем IE9.

Он будет работать для других популярных браузеров, таких как Chrome, Mozilla, Opera, Safari и т. Д.

Те из вас, кто использует Node.js и Express, могут установить cookie-файл сеанса, который запомнит URL текущей страницы, что позволит вам проверить реферер при загрузке следующей страницы. Вот пример, который использует промежуточное ПО express-session :

Затем вы можете проверить наличие cookie-файла referer следующим образом:

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

Если вы пишете веб-приложение или одностраничное приложение (SPA), в котором маршрутизация выполняется в приложении / браузере, а не в обратном направлении на сервер, вы можете сделать следующее:

Затем в вашем новом маршруте вы можете сделать следующее, чтобы получить предыдущий URL:

document.referrer не совпадает с фактическим URL во всех ситуациях.

У меня есть приложение, где мне нужно установить frameset с 2 кадрами. Один кадр известен, другой - это страница, на которую я ссылаюсь. Казалось бы, document.referrer было бы идеально, потому что вам не нужно было бы передавать фактическое имя файла в документ набора фреймов.

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

Мне понадобилось немного времени, чтобы понять это. Таким образом, в массиве истории document.referrer является не только URL-адресом, но, по-видимому, также спецификацией окна реферера. По крайней мере, это лучший способ понять это сейчас.

Если вы хотите перейти на предыдущую страницу, не зная URL-адреса, вы можете использовать новый API History.

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

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

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

Тем не менее, стандарты RFC не являются обязательными, и данные могут быть считаны. Несколько лет назад Facebook имел серьезные проблемы, когда выяснилось, что иногда идентификатор инициирующей страницы передавался рекламодателям в заголовке referer, когда пользователь нажимал на объявление .

Метатег referrer

Потенциальным решением этих проблем может стать метатег referrer . Добавляя к исходной странице:

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

Список параметров для поля контента :

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

В качестве практического примера: если бы facebook реализовал этот тег следующим образом:

то, когда мистер Бобби Тейблз зашел бы на Facebook , URL-адрес его страницы выглядел бы так:

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

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

Будьте осторожны

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

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

Заголовок отсутствует, если

Подводя итоги

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

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

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

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

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

Если вы не уверены в разнице между «сайтом» и «источником», ознакомьтесь со статьей «Понимание "same-site" и "same-origin"».
В Referer отсутствует буква R из-за неправильного написания в спецификации. Заголовок Referrer-Policy и referrer в JavaScript и DOM написаны правильно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

strict-origin-when-cross-origin (см. закрытую ошибку)
strict-origin-when-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, панель Network с выбранным запросом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используйте токены 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 отсутствует или если он присутствует и ваша базовая проверка заголовка Referer прошла успешно: вы можете перейти к другому, более надежному методу проверки (см. ниже).

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

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

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

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

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

Заголовки — это метаинформация, которую мы обычно не видим.

В заголовках запроса могут быть такие данные как:

предпочитаемые языки
характеристика программы, которая делает запрос
содержимое кукиз
информация для сервера — для какого хоста предназначен запрос и прочее

В заголовках ответа могут быть такие данные как:

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

Это самый простой способ, доступный в любой операционной системе.

Нажмите в веб-браузере F12 и откройте интересующую вас страницу. Перейдите на вкладку Network (сеть) и выберите интересующее вас подключение.

Вначале идут Заголовки ответа (Response Headers), а затем Заголовки запроса (Request Headers), хотя, конечно же, вначале отправляется запрос и его заголовки, а затем приходит ответ.

Опция -i также показывает только заголовки ответа, не показывает TLS рукопожатие, но зато показывает всё тело ответа.

Пример использования метода HEAD:

Пример вербального вывода:

Отправленные на веб сервер заголовки имеют в начале символ >, а полученные с веб-сервера строки начинаются на <.

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

И ещё смотрите близкую по теме статью: Как отобразить данные POST с cURL.

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