Краткая история заголовка referer

Если я нажимаю на ссылку на сайте, заголовок http referer указывает на исходную страницу, с которой я перешла на целевую страницу:

Source URL = www.mysite.com/page1 -> Target URL = www.example.com
referer = "www.mysite.com/page1"

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

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

В спецификации RFC2616 о referer говорится, что: "Клиенты не должны включать поле заголовка Referer в незащищенный HTTP-запрос, если исходная страница использовала защищенный протокол". То есть, если наш запрос ведет с HTTPS-страницы на HTTP, заголовок Referer не должен включаться.

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

Кроме этого, когда трафик проходит между двумя HTTPS сайтами (SSL становится все более распространенным) RFC не требует, чтобы заголовок server http referer удалялся.

Метатег referrer

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

<meta name="referrer" content="origin">

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

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

  • no-referrer: не опускать заголовок referrer из запроса;
  • no-referrer-when-downgrade: не пропустить заголовок referrer при переходе с HTTPS на HTTP;
  • origin: установить заголовок http referer таким образом, чтобы указать в нем только исходный сайт;
  • origin-when-cross-origin: если запрос ведет на другой сайт или протокол, установить для заголовка referrer параметр origin;
  • unsafe-url: установить заголовок referrer таким образом, чтобы в нем передавалась полная информация исходного URL-адреса.

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

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

<meta name="referrer" content="origin" id="meta_referrer" />

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

https://www.facebook.com/bobbytables?f=nref

Когда он нажал на внешнюю ссылку и перешел на другой сайт, заголовок http referer выглядел бы так:

referer=www.facebook.com

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

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

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

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

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

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

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

  • пользователь вводит URL-адрес в адресной строке браузера;
  • пользователь зашел на сайт через закладки;
  • запрос ведет с протокола HTTPS на HTTP;
  • запрос ведет с протокола HTTPS на различные URL-адреса с протоколом HTTPS;
  • защитное программное обеспечение (антивирус, брандмауэр и т.д.) очистило запрос;
  • прокси-сервер очистил запрос;
  • плагин браузера очистил запрос;
  • сайт был посещен программно (например, с помощью curl) без установки заголовка;
  • это запрещает метатег referrer;
  • это разрешает метатег referrer это разрешает, но браузер его не поддерживает.

Для сайтов, которые задействуют заголовок http referer в рекламных кампаниях, его некорректное использование может стать проблемой. Правила прокси-серверов, разрешающие доступ для пользователей, переходящих с конкретных сайтов, формирует высокий риск того, что это не будет работать вообще (в зависимости от браузера пользователя или локальной настройки). И возникнут уязвимости для злоупотреблений заголовками.

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

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

Вадим Дворниковавтор-переводчик статьи «A brief history of the referer header»