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


Оглавление (нажмите, чтобы открыть):

Fetch: запросы на другие сайты

Если мы сделаем запрос fetch на другой веб-сайт, он, вероятно, завершится неудачей.

Например, давайте попробуем запросить https://example.com :

Вызов fetch не удался, как и ожидалось.

Ключевым понятием здесь является источник (origin) – комбинация домен/порт/протокол.

Запросы на другой источник – отправленные на другой домен (или даже поддомен), или протокол, или порт – требуют специальных заголовков от удалённой стороны.

Эта политика называется «CORS»: Cross-Origin Resource Sharing («совместное использование ресурсов между разными источниками»).

Зачем нужен CORS? Экскурс в историю

CORS существует для защиты интернет от злых хакеров.

Серьёзно. Давайте сделаем краткое историческое отступление.

Многие годы скрипт с одного сайта не мог получить доступ к содержимому другого сайта.

Это простое, но могучее правило было основой интернет-безопасности. Например, хакерский скрипт с сайта hacker.com не мог получить доступ к почтовому ящику пользователя на сайте gmail.com . И люди чувствовали себя спокойно.

В то время в JavaScript не было методов для сетевых запросов. Это был «игрушечный» язык для украшения веб-страниц.

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

Использование форм

Одним из способов общения с другим сервером была отправка туда формы

Таким способом было возможно сделать GET/POST запрос к другому сайту даже без сетевых методов, так как формы можно отправлять куда угодно. Но так как запрещено получать доступ к содержимому с другого сайта, прочитать ответ было невозможно.

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

Использование скриптов

Ещё один трюк заключался в использовании тега script . У него может быть любой src , с любым доменом, например

Комментарии

  • Если вам кажется, что в статье что-то не так — вместо комментария напишите на GitHub.
  • Для одной строки кода используйте тег , для нескольких строк кода — тег

, если больше 10 строк — ссылку на песочницу (plnkr, JSBin, codepen…)

  • Если что-то непонятно в статье — пишите, что именно и с какого места.
  • Краткая история заголовка referer

    HTTP referer — The referer, or HTTP referer, >Wikipedia

    HTTP Referer — Référant Pour l’article homophone, voir Référent. Un référent ou référant, plus connu sous l anglicisme referer ou referrer[1], est, dans le domaine des réseaux informatiques, une information transmise à un serveur HTTP lorsqu un visiteur… … Wikipédia en Français

    HTTP referrer — HTTP Persistence · Compression · HTTPS Request methods OPTIONS · GET · HEAD · POST · PUT · DELETE · TRACE · CONNECT Header fields Cookie · ETag · Location · Referer DNT · … Wikipedia

    HTTP — Название: Hypertext Transfer Protocol Уровень (по модели OSI): Прикладной Семейство: TCP/IP Создан в: 1992 г. Порт/ >Википедия

    Referer spam — is a kind of spamdexing (spamming aimed at search engines). The technique involves making repeated web site requests using a fake referer url that points to the site the spammer wishes to advertise. Sites that publicize their access logs,… … Wikipedia

    HTTP cookie — HTTP Persistence · Compression · HTTPS Request methods OPTIONS · GET · HEAD · POST · PUT · DELETE · TRACE · CONNECT Header fields Cookie · ETag · Location · Referer DNT · … Wikipedia

    HTTP 404 — HTTP Постоянное соединение · Сжатие · HTTPS Методы OPTIONS · GET · HEAD · POST · PUT · DELETE · TRACE · CONNECT · PATCH Заголовки Cookie · ETag · Location · Referer DNT · X Forwarded For … Википедия

    HTTP pipelining — HTTP Постоянное соединение · Сжатие · HTTPS Методы OPTIONS · GET · HEAD · POST · PUT · DELETE · TRACE · CONNECT · PATCH Заголовки Cookie · ETag · Location · Referer DNT · X Forwarded For … Википедия

    Referer spoofing — In computer security, referer spoofing or ref tar spoofing is the sending of incorrect referer information along with an HTTP request, sometimes with the aim of gaining unauthorized access to a web site. It can also be used because of privacy… … Wikipedia

    Referer-Spam — Referrer Spam (auch Logdatei Spam) ist eine Sonderform des Suchmaschinen Spamming. Hierbei werden Webseiten massenhaft aufgerufen, damit sie in den Referrer Informationen der Statistiken der angegriffenen Webseiten auftauchen. Inhaltsverzeichnis… … Deutsch Wikipedia

    IntSystem.org

    Случаи из опыта разработки различных WEB проектов. Интересные факты, статьи, впечатления. Программирование и все о нем в сфере WEB.

    Уязвимость CSRF. Скрываем Referer при редиректе

    Сегодня я дополню цикл статей про CSRF. Но теперь я буду плавно переходить на «ту сторону баррикад». Как говорится кто предупрежден, тот вооружен. Если разработчик будет знать как орудует злоумышленник то он будет знать как и от чего защищаться.

    Эта статья является переработанным переводом статьи «Stripping Referrer for fun and profit» зарубежного автора Krzysztof Kotowicz. Мне понравились методы используемые в его статье и я хочу поделится ими с вами. Обращу ваше внимание что это все же переработанный перевод, так как часть материала предложенного в оригинале я уже изложил у себя в статьях, и дублировать его я смысла не вижу.

    В общем если вас интересует как отредеректить пользователя без указания Referer то прошу под кат 🙂

    Что такое реферер?

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

    Пример использования реферера

    Иногда реферер используется в качестве механизма контроля доступа. А началось все с ссылок на чужой контент. Спам сайты начали добавлять чужой контент (например, изображения) с других сайтов, простой вставкой Для поситителей это было не заметно, и спам страница выглядела для них вполне легально, но этим самым она воровала пропускную способность (и контент) оригинального сайта. Чтобы не допустить этого, разработчики начали проверку заголовка Referer, который передавал браузер. Если URL реферера содержал оригинальный веб-сайт, то сервер вернет изображение. Если реферер содержал адрес другого сайта то сервер возвращал ошибку.

    Подходим к CSRF

    Затем появилась CSRF. Любой веб-сайт может отправить потенциально опасные запросы к уязвимым сайтам и, например, удалить аккаунт на уязвимом сайте, изменить адрес электронной почты или настроить почтовый фильтр и прочее в тайне от пользователя. Некоторые веб-разработчики стали добавлять простой механизм защиты: они стали проверять реферер! Осуществлялась эта проверка следующим образом:

    • Если Referer содержит адрес своего хоста то обрабатываем запрос
    • В других случаях запрос блокируется

    Казалось бы задача решена. Только допустимые страницы могут слать успешные запросы. Но появилась одна проблема — что делать с пользователями у которых отключен Referer? Они просто не смогут пользоваться данным приложением так как их запросы будут блокироваться. Во многих системах это было решено следующим образом: подобная ситуация с отсутствием реферера трактовалась в сторону пользователя и запрос считался легальным и поступал на обработку.

    Скрываем Referer

    Такое решение проблемы создало огромную дыру в безопасности и злоумышленники начали искать способы этим воспользоваться. Было предложенно несколько методов подобного сокрытия но с использованием серверных технологий редиректа. Но данные методы мало интересны так как они довольно известны. Я же хочу предложить вам другой вариант — возможность редиректа пользователя с генерацией произвольного GET или POST запроса только со стороны клиента на чистом яваскрипте.
    Вот примеры реализаций:

    function lose_in_webkit(url) <
    // chrome loses it in data uris
    location = «data:text/html,

    Получение с сайта заголовка Referer для последующей отправки его на сайт

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

    Добавлено через 1 час 11 минут
    Может не понятно выразился , нужно каким то образом получить с сайта значение заголовка Referer , а потом это значение отправлять с последующими запросами на этот сайт. Потому что каждый раз после входа-выхода на сайт значение referer меняется на новое в случайном порядке. К примеру зашел я на сайт , мне выдало реферер.
    Host 109.234.155.164
    X-Requested-With XMLHttpRequest
    User-Agent Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
    Accept text/plain, */*
    Referer https://xxx.xxx.xxx.xxx/yyyy/xxxx.php?s > Accept-Encoding gzip,deflate,sdch
    Accept-Language ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
    Accept-Charset windows-1251,utf-8;q=0.7,*;q=0.3
    Cookie = xxxxxxx

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

    23.01.2012, 22:43

    Получение заголовка сайта
    Вопрос такой. Имеется код (работающий) для получения заголовка сайта по его адресу, сейчас я хочу.

    Получение заголовка сайта (кодировка)
    Хочу получить заголовок сайта. Заголовок возвращается, но в непонятной кодировке. Побывал.

    Конвертация времени из Gregorian формата в TIMSTAMP для последующей отправки в БД Derby
    Доброго времени суток господа. Столкнулся я с не преодолимой, как оказалось для меня, задачей =).

    Как при помощи C# отправить выбранный файл в outlook для последующей отправки на почту?
    Например имеем форму с кнопкой на ней, требуется при нажатии на кнопку открыть Outlook и добавить.

    Создание TCP/IP заголовка для отправки по Raw сокету
    Вкратце, я для ознакомительных целей пишу syn flood dos программу(самая безобидная атака из всех :).

    23.01.2012, 23:26 2 24.01.2012, 01:50 [ТС] 3

    referer принимает значения из textBox4.Text , в который я и ввожу нужный реферер с сидом который получил через снифер.

    Добавлено через 1 час 22 минуты
    Видимо нужно до HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url); использовать какой то метод на подобии куки контейнера,только для Referer и оттуда брать значение referer при отправке запроса. Если что то подобное есть , посоветуйте как реализовать. Потому что каждый раз сниффером пользоваться для вылавливания создаваемых сайтом sid в Referer не вариант.

    Мастер Йода рекомендует:  UnityC# разработчик

    Добавлено через 27 минут
    Если ещё что то не понятно изложил , или не достаточно инфы , скажите , я добавлю все что нужно , очень необходимо решить эту проблемку.

    24.01.2012, 03:27 4
    24.01.2012, 03:27
    24.01.2012, 05:28 [ТС] 5
    24.01.2012, 10:58 6
    24.01.2012, 19:48 [ТС] 7

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

    Посмотрите вот это приложение
    https://vkontakte.ru/app1859470_30582356?ref=1
    Я работаю на данный момент с ним.

    Добавлено через 6 часов 55 минут

    24.01.2012, 19:58 8
    24.01.2012, 20:36 [ТС] 9
    24.01.2012, 21:05 10
    25.01.2012, 19:17 [ТС] 11

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

    Добавлено через 3 часа 38 минут
    Сделал как в статье , вот код. Я уже второй день бьюсь над этим вопросом и как не пытаюсь вытащить эти куки , нихрена они не вытаскиваются.

    Вроде бы все понятно , но не пойму где я допускаю ошибку , с этим кодом сервер возвращает:

    GET /piwar/m/tavern.php?a=3&i=3&m=27&rnd=0.0833441826980561 HTTP/1.1
    Accept application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    User-Agent Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16
    Host 109.234.155.164

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

    Добавлено через 13 часов 56 минут
    up

    Добавлено через 32 минуты
    https://vkontakte.ru/app1859470_30582356?ref=1 с этого приложения вообще реально вытащить каким либо образом Referer или Cookie ? Посмотрите кто лучше разбирается.

    Добавлено через 3 часа 59 минут
    Ну что ни кто не знает как из этого мудреного приложения куки вытащить?

    25.01.2012, 20:12 12
    26.01.2012, 19:53 [ТС] 13

    Все перечитал , уже около 5ти способов перехвата и отправки куков знаю ))))) И даже узнал что такое куки и их историю ))) это приложение авторизации не требует , т.к. даже после выхода каким то волшебным образом сессия ещё сохраняется в течении 5-10 минут , т.е. за счет правильных кук я могу посылать туда запросы и т.д. Потому вытащить оттуда куки очень необходимо.
    Ладно , допустим с приложения ни как не получается , а что если брать куки из браузера ? Он же их сохраняет локально.

    Добавлено через 16 часов 16 минут
    Пожалуйста ув. sau , у Вас опыта больше , посмотрите возможно ли как то выдрать куки из приложения выше =) Может быть я использую совсем не эффективные методы. И я не ищу легких путей ,что б за меня все решили, но если у Вас получится , то Вы хотя бы сможете дать верное направление в котором копать ) А если не получится у Вас, что врятли , тогда я не буду пока что забивать голову решением этой проблемы и больше углублюсь в изучение базовых понятий и принципов языка.

    Добавлено через 1 час 0 минут

    Добавлено через 1 час 33 минуты
    ап ап

    Добавлено через 49 минут

    Добавлено через 1 час 35 минут

    Такие разные заголовки! Изучаем HTTP-взаимодействие

    Содержание статьи

    Большинство из нас многократно слышали про способность сайтов узнавать информацию о посетителе (и всевозможные предупреждения по этому поводу), которую невозможно узнать из IP-адреса. Это такие «личные» данные, как операционная система, используемый браузер, язык системы. Кто же так жестоко палит нас? И как можно это использовать в своих благих намерениях? Об этом и многом другом ты узнаешь, прочитав статью до конца.

    Для начала приведу немного теории о том, чем мы пользуемся довольно давно. HTTP (HyperText Transfer Protocol – «протокол передачи гипертекста») – клиент-серверный протокол передачи данных, который служит для получения информации с веб-сайтов. Был предложен создателем всея WWW Тимом Бернерсом-Ли. Структура его проста: тип сообщения, заголовки, тело сообщения. Существуют RFC, стандартизирующие HTTP (последняя версия – 1.1), согласно которым клиент должен посылать серверу заголовки, содержащие ту самую специфическую информацию о системе и браузере. Обычному пользователю это полезно: сайт в зависимости от клиента может выдать специфическую верстку (пример – google.com) или показать информацию на нужном языке. Однако для хакера раскрытие такой информации может быть вредно или даже опасно.

    Представим ситуацию: некий Иван зашел на сайт, посмотрел на него и решил взломать. Загрузил проверенные соксы, поставил красивый дефейс и через несколько часов/дней сидел в участке. Ведь несложно сопоставить данные взломщика с данными остальных посетителей и найти настоящий IP (очень редко встретишь сайт без логирования). Да, некоторые факторы не учтены, однако, вариант возможный.

    Техническая реализация

    Итак, нам необходимо подделывать заголовки, которые браузер шлет серверу. Как кросс-браузерное решение я бы предложил старый быстрый Proxomitron. Изначально он предназначен для удаления рекламы и полного управления содержимым страницы, так что замечательно подходит для наших целей. Работает как HTTP-прокси. С первого взгляда интерфейс Proxomitron’а не очень дружелюбен, однако разобраться в нем – дело нехитрое. Если нужно использовать только подделку заголовков – слева убираем все галки кроме второй. Жмем на «Headers» и редактируем правила подмены: сразу после установки – в списке куча правил, добавить свое можно, нажав на кнопку New. Чтобы задействовать фильтр, нужна галка в поле «out». Обязательно прочитай русский хелп к программе – там отлично все расписано.

    Я пользуюсь Mozilla Firefox и предпочитаю вместо внешних программ использовать плагины. Tamper Data позволяет перехватывать запросы и редактировать заголовки в реальном времени – незаменимая вещь при ручной проверке. Все просто: в окне плагина жмем «Запустить перехват» и вмешиваемся, когда необходимо. Имеются пресеты и богатые возможности по изменению значений заголовков.

    Для постоянной же подмены заголовков лучше использовать плагин Modify Headers. Сразу после установки необходимо открыть настройки и поставить галку на «Always on», дабы подмена происходила всегда. Настройка элементарная – открыть главное окно плагина и добавить правил. Первое поле – выбор действия («Add» – добавить, «Modify» – изменить, «Filter» – исключить из запроса), второе – название заголовка, третье – значение; в четвертом поле можно оставить записку. Правила можно двигать, включать и выключать.

    Вектор поиска

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

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

    Пассивные XSS основаны на том, что запрос будет делать непосредственно пользователь. Заставить жертву подменить заголовок едва ли удастся, именно поэтому этот тип нам не подходит. Единственная возможность использовать найденные подменой заголовков пассивные XSS – это если на страницу пишется Referer (ссылающаяся страница), да не простой, а дополнительно декодированный (избавленный от %xx). Тогда можно скриптом перенаправить жертву на себя с нужным параметром и после – на уязвимую страницу, так что параметр запишется в месте Referer’а. Сработает в идеальных условиях, на практике также не встречал.
    Активные XSS подходят. Смысл в том, чтобы веб-приложение занесло в базу наш заголовок, а после показало администратору, естественно, не обработав.

    SQL-инъекции подходят. Это самый простой тип, достаточно, как и обычно, подставлять кавычку.

    PHP-исполнение кода очень редко встречается вообще, а с участием заголовков – еще реже. Однако бывает. Тут преимущество нашего метода в том, что GET и POST данным менее доверяют.

    Итак, теперь необходимо составить строку, которая позволяла бы определить наличие уязвимости. Кавычка обязательна. Далее необходимо выйти из возможных тегов: простейший способ сделать это символами «>. И последнее – алерт, дабы не проспать. В итоге у меня вышло ‘»>. Ставить на обнаружение исполнения кода я не стал; если желаешь, добавь, например, чтобы вызвать ошибку и заметить уязвимость. Также можно добавить в конец обратный слеш (пытаясь экранировать закрывающую кавычку), бывают случаи с фильтрацией кавычек, бывают без нее. Считаешь, что строка слишком длинная и может обрезаться? Замени “document.cookie” на «1». Тут главное – приложить фантазию и создать свой идеальной вектор поиска уязвимостей.

    Интересные заголовки

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

    User-Agent

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

    Браузер/Версия (Платформа; Шифрование; Система, Язык[; Что-нибудь еще]) [Дополнения].

    В качестве платформы чаще всего можно увидеть X11 или Windows, иногда туда прямиком помещают систему, убирая соответствующий заголовок после. «Шифрование» может принимать три значения: “N” (None) – отсутствует, “I” (International) – слабое шифрование ключом до 40 бит, “U” (USA) – сильное шифрование с ключом 128 бит. Сейчас все браузеры используют только сильное шифрование. После скобки добавляется различная информация вроде движка, плагинов, дополнений.

    В качестве браузера для совместимости очень часто указывают Mozilla, а уже после информации дописывают реальное название. Это связано с тем, что издавна девелоперы должны были (или просто любили) делать сайты не в соответствии с принятыми стандартами Консорциума Всемирной паутины (World Wide Web Consortium, W3C), а под наиболее распространенные в данное время браузеры, что приводило к еще большему доминированию последних. И сейчас такая практика существует, однако с тем отличием, что популярным браузерам даны дополнительные возможности, связанные с использованием JavaScript’а (например, на распространенном форуме Invision Power Board, в ветке 2.3.x, посмотрите профиль участника с отфильтрованным заголовком и без). Поэтому советую в строку User-Agent’а в любом случае включать определение распространенного браузера.

    Referer

    Сообщает о странице, с которой пришел пользователь. Заголовок, сильно полезный веб-мастерам для отслеживания путей попадания на их сайты. Написание – ошибка от английского «Referrer» («перенаправляющий»). Большинство браузеров позволяет отключать передачу этого заголовка, однако при этом обычно возникают проблемы с файлообменниками и сайтами-архивами, которым очень жалко отдавать контент без показа рекламы, так что они позволяют скачивать только при наличии их сайта в реферере. Можно подменять ради просмотра отдельных элементов сайта – например, картинок – без загрузки страниц, где они размещены (при условии, что без подделки это сделать не удастся). При пентесте стоит учитывать, что часто в базу записывают URL не полностью, а лишь нужную его часть, поэтому стоит пробовать «https://evil», «https://example.com/evil» и т.д.

    X-Forwarded-For

    Нестандартный заголовок, используемый неанонимными прокси-серверами для передачи реального IP клиента. Мы не можем вставить кавычку в определяемый сервером IP, зато можем заставить его думать, что это – всего лишь прокси, а настоящий IP – вот он, в X-Forwarded-For. Конечно, далеко не все скрипты используют и полагаются на XFF, но этот заголовок принято хотя бы логировать. Нельзя забывать проверять веб-приложение на наивность (да-да, некоторые сайты, увидев этот заголовок, забывают про обычный IP и пользуются только тем, что передано в данном заголовке). Формат: X-Forwarded-For: client_ip, proxy1_ip, . proxyN_ip.

    Accept-Language

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

    Accept-Charset

    Сообщает допустимые кодировки и их приоритет. Не самый интересный заголовок, но стоит обратить на него внимание, ибо он может выдать твою систему простым «windows-1251».

    X-Requested-With

    Нестандартный заголовок, сообщает средство запроса. Используется при запросах из JavaScript без перезагрузки страницы. Соответственно полезен для имитации AJAX (Asynchronous Javascript and XML) запросов, для этого необходимо установить его в значение «XMLHttpRequest».

    Authorization

    Если серверу необходима авторизация пользователя, он об этом прямо сообщает, а браузер предлагает ввести логин и пароль. Именно в заголовке Authorization они передаются в виде «Basic base64(user:pass)». Такую авторизацию намного удобней брутить, чем те, которые располагаются непосредственно на странице (POST).

    Cookie

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

    Применение

    Итак, практика. Я проводил исследование, в ходе которого некоторое время использовал «пассивное обнаружение уязвимостей». Суть в том, что достаточно однажды выставить замену заголовков, а после – лишь ловить алерты и исследовать бреши.

    ЗаголовокЗначениеВключен
    User-Agent Opera/10.60 Да
    Referer Да
    X-Forwarded-For Да
    Accept-Language en,en-US;q=0.9 Нет
    AuthorizationBasic MScyMzo0JzU2 Нет
    X-Requested-WithXMLHttpRequest Нет
    CookiePHPSESS >

    С первыми тремя, думаю, понятно. Если в ладах с английским, включи на постоянную подмену Accept-Language, дабы принимали за англичанина. Authorization уместно включать только при проверке конкретного сайта, ибо рискуете не понять, если где-нибудь действительно понадобится авторизация. Про применение заголовков X-Requested-With и Cookie я уже писал, однако поясню последний. В PHP довольно удобно хранить данные в сессиях: собственно данные – на сервере, у клиента – только идентификатор в куке «PHPSESSID» (название можно менять, но делают это, естественно, редко). Так вот, иногда этот идентификатор может состоять только из символов a-z, A-Z, 0-9 и ‘-,’, и при передаче чего-то иного вызывается ошибка, раскрывающая абсолютный путь:

    Warning: session_start() [function.session-start]: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and ‘-,’ in /var/www/data/www/login.php on line 2

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

    Никто не знает и не узнает, сколько алертов выловили админы, сколько они их увидели у себя в логах, сколько осталось незамеченными. Однако один случай обнаружения интересной активной XSS есть точно – гугловский сервис FeedBurner, который умеет обрабатывать RSS-фиды и логировать трафик сайта. Но последнее делал он не слишком качественно – не фильтровался Referer. Подробнее об этой уязвимости читай на raz0r.name/vulnerabilities/aktivnaya-xss-na-feedburner/ (wp.me/pft5J-4a) (не удивляйся, увидев алерт из-за XFF :)).

    Довольно весело было заходить на всякие сайты с DLE (DataLife Engine), ибо популярный модуль DLE Referer Module не дружил (и не дружит) с экранированием плохих символов. Для убедительности советую пройтись по сайтам продавцов ICQ UIN’ов и увидеть много MySQL-ошибок, хотя картина уже не будет слишком печальной – я разослал владельцам сообщения об уязвимости, ведь неприятно, когда твои платежные данные и ссылки на оплату можно подменить.

    Некоторое время назад на php.ru можно было наблюдать ошибки нефильтрации Referer’а и XFF. На данный момент уязвимость закрыта. Из ошибки с реферером:

    MySQL Error = You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘»‘)’ at line 1

    SQL = INSERT INTO oops_sessions (ID,UID,START,LAST,IPS,PAGES,PAGE,DATA,REFFER) VALUES (‘dpdu7rh90ehfsc62′,’0′,1238958331,1238958331,’xxx.xxx.xxx.xxx’,1,’/’,’a:1:‘,’SQL-Inj’here’)

    Еще один пример – cx75planet.ru. Уязвимы User-Agent и XFF. IPB показывает весь запрос. Кроме этих брешей, была замечена еще туча SQL-ошибок на сайтах всех мастей, большинство из которых просто имели самописные модули обработки информации о браузерах, рефах и т.д. Предоставляю тебе возможность найти их все :).

    Подмена заголовков в PHP

    Естественно, после ручного анализа SQL-уязвимости наступает работа автоматики. Подбор столбцов, полей, вынимание логинов, паролей и хешей – все уже давно делают скрипты. Однако большинство из них направлено на GET, POST или Cookie. Покажу, как можно получить страницу, посылая нужные заголовки. Предположим, у нас есть массив с такими заголовками и вызов функции request, которая должна возвращать страницу:

    $headers = array (
    ‘User-Agent: Babytoy/0.5’,
    ‘Referer: https://refrefref.ref/omg.pl’
    );
    $html = request_socket(‘https://127.0.0.1/showmeheaders.php’, $headers);
    echo $html;

    Есть несколько основных видов получения страницы из PHP (полные версии функций ищи на диске ][):

    Сокет

    Заголовки напишешь в любом случае. Генерация пакета:

    $packet = «GET <$url>HTTP/1.1rn»
    . «Host: <$host>rn»
    . implode(«rn», $headers) . «rn»
    . «Connection: Closernrn»;
    — file_get_contents()

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

    $opts = array (
    ‘http’ => array (
    ‘header’ => implode(«rn», $headers) . «rn»
    )
    );
    $context = stream_context_create($opts);
    return file_get_contents($url, false, $context);

    В curl’е все проще простого: вместе с остальными параметрами достаточно указать curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);

    Заключение

    Хотелось бы обратить внимание, что подмена заголовков – не панацея от сливания информации. Не стоит забывать о JavaScript’е, Flash’е и интерактивных элементах, которые тоже вправе много чего разболтать. Используй NoScript и прочие AdBlock’и. Всегда экспериментируй и прикладывай выдумку, ищи там, где не ищет никто. Удачи!

    О пользе мета-тега «referrer» в эпоху шифрования

    Автор: Сайрус Шепард (Cyrus Shepard) — сотрудник команды Moz, ранее занимался исключительно вопросами поисковой оптимизации, сегодня в большей степени сосредоточен на создании продвигающего контента и технических аспектах его распространения и отслеживания статистики. Сайрус Шепард не раз возглавлял кампании по продвижению в интернете крупных и авторитетных брендов.

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

    Усилия представителей поиска возымели эффект, и сегодня мы можем наблюдать в результатах поисковой выдачи все большее и большее число ресурсов, использующих протокол HTTPS. Результаты недавнего исследования MozCast свидетельствуют, что на сегодняшний день около 20% результатов, показывающихся на первой странице выдачи Google, ведут на защищённые страницы:

    К сожалению, использование протокола HTTPS сайтами имеет и свои, довольно весомые недостатки. Переход с HTTP на HTTPS доставил массу трудностей и технических неудобств интернет-маркетологам.

    Первая проблема была связана с вынужденным применением кода ответа сервера 301 для перенаправления пользователей на безопасные версии страниц. Исторически данный тип перенаправлений ассоциировался у профессионалов отрасли с потерей ссылающейся страницей ссылочного веса, как минимум на 15%, что само собой может привести к снижению её видимости в результатах поисковой выдачи. Одна только эта проблема способна перечеркнуть все обещанные Google преимущества.

    Эксперт отрасли Росс Хадженс (Ross Hudgens) идеально сформулировал проблему в своём твите: ««HTTPS как фактор ранжирования». Перевод с HTTP на HTTPS с применением 301 редиректа ведет к потере ссылочного веса. Выгода от перехода на HTTPS — незначительная, зато потеря ссылочного веса – ощутима. Трафик теряется».

    «HTTPS is a ranking factor». 301 HTTP to HTTPS. Links lose equity through 301. HTTPS gain is less than amount of equity loss. Lose traffic.

    Тем не менее, на пике событий многие оптимизаторы радостно делились историями успешного перевода своих ресурсов на безопасный протокол HTTPS, рапортуя о том, что видимость безопасных страниц в SERP Google даже улучшилась. Вскоре использование HTTPS на сайте было официально объявлено сигналом ранжирования для Google и даже вошло в список факторов ранжирования по итогам 2014 года. Трудно поверить, но перевод сайта на HTTPS дает чрезвычайно кратковременный эффект. Впоследствии позиции ресурса в выдаче и вовсе снижаются. Так перевод блога Moz на протокол шифрования, призванный обеспечить большую конфиденциальность работы с ресурсом для зарегистрированных пользователей, привел к снижению видимости страниц в результатах органической выдачи Google на 8-9%.

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

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

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

    Когда трафик с сайтов, защищённых протоколом HTTPS, поступает на ресурсы, применяющие HTTP, реферальные данные не передаются, и вебмастеру становится невозможно определить, из каких источников он поступает.

    Вот как выглядела статистика переходов на персональный блог автора данной статьи с ресурса Moz после перевода последнего на HTTPS:

    Зачем нужен мета-тег «referrer»?

    Поскольку решение проблемы традиционными методами становится затруднительным, приходится решать вопрос за счёт применения иных методов. Следует признать, что большинство интернет-маркетологов еще не слишком хорошо осведомлены о существовании альтернативных путей и возможностей отслеживания данных о входящем трафике. Выйти из ситуации, к примеру, помогает использование мета-тега «referrer», который появился несколько лет назад. Он позволяет контролировать процесс передачи реферальных данных. Мета-тег поддерживается всеми основными браузерами и передает данные о реферерах, согласно пользовательским настройкам. При этом трафик остается зашифрованным, а пользователи получают все преимущества от применения сайтом протокола HTTPS. Тем не менее, владелец ресурса получает возможность передавать данные о переходах на любые веб-сайты, включая те, которые до сих пор применяют протокол HTTP.

    Как использовать мета-тег «referrer»?

    Ниже представлены упрощенные инструкции по использованию мета-тега «referrer». Тем, у кого есть желание углубиться в тему подробнее, автор статьи рекомендует ознакомиться со следующим документом.

    Полезными также могут оказаться и следующие ссылки:

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

    Типы значений могут быть следующими:

      None: Никогда не передает реферальные данные:

    None When Downgrade: Передает реферальные данные сайтам на HTTPS, в то время, как сайтам на HTTP данные не передаются.

    Origin Only: Передает данные о хостах и поддоменах. При этом URL , как правило, имеет следующий вид: https://moz.com/example.html would simply send https://moz.com (пример).

    Origin When Cross-Origin: Передает полные данные о URL в случаях, когда настройка произведена по схеме №3 вне зависимости от того, какой протокол использует сайт HTTP или HTTPS.

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

    Мета-тег в действии

    Увидеть, как работает мета-тег «referrer», можно, совершив переход по следующей ссылке. Такое значение URL можно получить, если выбрать в качестве его настройки параметр «Origin». При такой настройке параметров тега данные о реферере передаются схеме: хост и поддомен. В данном случае в качестве итогового результата показывается следующий адрес сайта перехода: https://moz.com.

    На практике данные аналитики до применения мета-тега «referrer» и после начала его использования выглядят так:

    Чтобы упростить процедуру отслеживания и сделать её максимально безопасной, большинство представителей сайтов предпочитают использовать параметр «Origin» при настройке мета-тега «referrer». Однако у данного подхода есть свои недостатки. Один из главных минусов заключается в том, что при настройке тега соответствующим образом для ресурса Moz, аналитика системы AdRoll, которую ресурс использует для ретаргетинга объявлений, перестает работать. В своей аналитике AdRoll использует данные Moz о реферальных переходах, в то же время параметр «Origin» подразумевает, что единственный URL, с которого перешел пользователь был https://moz.com. Таким образом, аналитика становится недействительной.

    Заключительные выводы

    Полюбить мета-тега «referrer» можно только за то, что он хоть каким-то образом позволяет передаваться по сети данным о переходах с защищенных сайтов. Так, что жизнь не останавливается!

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

    Как вручную установить заголовок REFERER в Javascript?

    Я хочу установить заголовок Referer моей веб-страницы. В настоящее время он отображает «xyz», и я хочу установить его на «abc».

    Просмотренный референт с помощью javascript:alert(document.referer)

    Вы не можете вручную установить заголовок Referer , но вы можете использовать location.href , чтобы установить заголовок Referer на ссылку, используемую в href , но это вызовет перезагрузку страницы.

    Вы можете использовать Object.defineProperty для объекта документа для свойства referrer:

    К сожалению, это не сработает ни на одной версии Safari

    Это работает в Chrome, Firefox, не работает в Safari:(, не тестировался в других браузерах

    тестовый пример: https://jsfiddle.net/bez3w4ko/ (так что вы можете легко протестировать несколько браузеров), и вот тест с iframes https://jsfiddle.net/2vbfpjp1/1/

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

    просто сделал фальшивый вызов ajax, он сделает запись в заголовке реферирования.

    Вы не можете изменить свойство REFERRER. То, что вы запрашиваете, — это подменить запрос.

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

    Вы можете изменить значение реферера в заголовке HTTP с помощью API веб-запросов.

    Для этого требуется фон js script. Вы можете использовать onBeforeSendHeaders, поскольку он изменяет заголовок перед отправкой запроса.

    Ваш код будет примерно таким:

    URL: он действует как фильтр запроса и вызывает слушателя только для определенных запросов.

    Если вы хотите изменить заголовок реферала (url), который будет отправлен на сервер при нажатии пользователем якоря или iframe, вы можете сделать это без каких-либо взломов. Просто запустите history.replaceState, вы измените URL-адрес, как он появится в панели браузера, а также референт, который будет отправлен на сервер.

    Посмотрите другие вопросы по метке javascript или Задайте вопрос

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

    Заголовки HTTP используются для «общения» браузера и web-сервера, например, когда браузер запрашивает какой-либо документ, он посылает заголовок GET, а когда сервер возвращает тип документа, то он делает это ни как-нибудь, а в заголовке Content-type.

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

    Итак, приведем список и краткое описание основных заголовков HTTP.

    Заголовок Accept

    Заголовок Accept предназначен для информирования сервера о типах данных, которые поддерживаются клиентом (браузером). В этом заголовке браузер перечисляет, какие типы документов он «понимает». Пере-
    числение идет через запятую.

    Используется переменная окружения HTTP_ACCEPT. Пример использования:

    Accept: text/html, text/plain, image/jpeg

    В последнее время вместо списка указывается значение *.*, что означает «все типы».

    Заголовок Content-type

    Данный заголовок предназначен для идентификации типа передаваемых данных. При этом заголовок Content-type использует переменную окружения CONTENT_TYPE. Обычно для этого заголовка указывается значение application/x-www-form-urlencoded. Таким образом, указывается формат, в котором все управляющие символы (т.е. символы, не являющиеся алфавитно-цифровыми) специально кодируются. О некоторых других MIME-типах вы можете узнать здесь.

    Это тот самый формат передачи, который используется методами GET и POST.

    Довольно распространен и другой формат, multipart/form-data.

    Сервер никак не интерпретирует рассматриваемый заголовок, а просто передает его сценарию через переменную окружения.

    Пример: Content-type: text/plain

    Заголовок Content-length

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

    Если задействуется метод GET, то этот заголовок отсутствует, и значит, переменная окружения не устанавливается.

    Заголовок Cookie

    В этом заголовке хранятся все Cookies. Данный заголовок использует переменную окружения HTTP_COOKIE. Для установки Cookies используется заголовок Set-Cookie.

    Заголовок GET

    Об этом заголовке мы упоминали ранее.

    Заголовок GET использует следующие переменные окружения:

    • REQUEST_URI — запрашиваемый идентификатор ресурса;
    • QUERY_STRING — передаваемые сценарию параметры;
    • REQUEST_METHOD — метод передачи информации. В данном случае эта переменная будет содержать значение GET.

    Заголовок Location

    Получив заголовок Location вместе с указанным в нем URL, сервер немедленно переходит по указанному URL, не дожидаясь, пока тело документа загрузится:

    Пример: Location: https://www.somehost.com/

    Заголовок POST

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

    Напомним формат заголовка POST: POST сценарий?параметры HTTP/1.0

    Заголовок Pragma

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

    Пример заголовка: Pragma: no-cache

    Данный заголовок содержит название и версию программного обеспечения сервера. Например:

    Server: Apache/1.3.23 (Unix) (Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b Dav/1.0.3 PHP/4.3.0 mod_perl/1.26 configured

    Заголовок Referer

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

    Переменная окружения: HTTP_REFERER.

    Заголовок User-Agent

    Содержит версию браузера. Например: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.0.0-10; Linux).

    Переменная окружения: HTTP_REFERER.

    Некоторые комментарии по HTTP-заголовкам

    Мы ознакомились с названиями заголовков и соответствующим им переменным окружения.

    Необходимо помнить основные приципы:

    • Все символы в верхнем регистре;
    • В начале имен добавляется HTTP_
    • Символы «-» заменяются знаком подчеркивания «_».

    Передача заголовков HTTP в PHP

    В PHP есть встроенные функции для работы с заголовками HTTP.

    Для передачи заголовков HTTP предназначена функция header()

    Приведем практические примеры:

    ( «Location: https://www.example.com/» ); /* Производит перенаправление браузера на другой ресурс */

    /* Внимание! Убедитесь, что код, расположенный ниже не исполняется */
    exit;
    ?>

    // Date in the past
    header ( «Expires: Mon, 26 Jul 1997 05:00:00 GMT» );

    // always modified
    header ( «Last-Modified: » . gmdate ( «D, d M Y H:i:s» ) . » GMT» );

    // HTTP/1.1
    header ( «Cache-Control: no-store, no-cache, must-revalidate» );
    header ( «Cache-Control: post-check=0, pre-check=0» , false );

    // HTTP/1.0
    header ( «Pragma: no-cache» );
    ?>

    HTTP referer

    Referer — ошибочное написание англ. referrer — отсылающий, направляющий — который в протоколе HTTP — является одним из заголовков запроса клиента. Содержит URL источника запроса. Если перейти с одной страницы на другую, referer будет содержать адрес первой страницы. Часто на HTTP-сервере устанавливается программное обеспечение, анализирующее referer и извлекающее из него различную информацию. Так, например, владелец веб-сайта получает возможность узнать, по каким поисковым запросам, как часто и на какие именно страницы попадают люди. Если HTTP-клиент загружает с сервера картинку, представленную на какой-либо странице, то referer будет содержать адрес этой страницы. Некоторые HTTP-серверы перед выдачей картинки анализируют referer и не показывают картинку, если запрос приходит с другого сайта (а, например, показывают маленькое изображение-заглушку).

    Любопытно, что написание английского слова referrer как referer — популярная ошибка. Настолько популярная, что вошла в официальные спецификации протокола HTTP.

    Как уже упоминалось, бывает, что сервер отказывается выдавать нужное содержимое без определённой строки referer, поэтому многое клиентское ПО имеет возможность выставить эту строку вручную. Например, wget поддерживает опцию «—referer», позволяющую выставить нужную строку и получить доступ к требуемому содержимому веб-сервера.

    Настройка referer в браузерах

    • В браузерах, основанных на Chromium, для отключения передачи Referer в свойствах ярлыка в поле объект надо добавить после пробела —no-referrers
    • В Mozilla Firefox работа с referer настраивается опциями « network.http.sendRefererHeader » и « network.http.sendSecureXSiteReferrer » в about:config. Также существует множество расширений для точной (например, посайтовой) настройки.
    • В Opera — Инструменты → Настройки → Дополнительно → Сеть → [ ] «Включить указание источника перехода».
    • В Opera 9.64 — Инструменты → Настройки → Дополнительно → Сеть → Отправлять данные о ссылающейся странице (F12 → Отправлять данные о ссылающейся странице).
    • В Opera 12 — Инструменты → Общие настройки → Расширенные → Сеть → Отправлять данные о ссылающейся странице (или F12 → Отправлять данные о ссылающейся странице).
    • В Comodo Dragon — Параметры → Дополнительные → Личные данные → Не позволять вебсайтам узнать, как вы на них попали (не посылать заголовок HTTP Referrer).

    См. также

    HTTP referer в Викиучебнике
    • Протокол HTTP
    • Заголовки HTTP

    Ссылки

    • RFC 2616: Hypertext Transfer Protocol — HTTP/1.1
    • IRI — Internationalized Resource Identifiers

    Что такое Wiki.sc Вики является главным информационным ресурсом в интернете. Она открыта для любого пользователя. Вики это библиотека, которая является общественной и многоязычной.

    Основа этой страницы находится в Википедии. Текст доступен по лицензии CC BY-SA 3.0 Unported License.

    Реферер

    – пользователь системы, который привлекает в эту систему других пользователей и получает за каждого привлечённого вознаграждение.

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

    Реферер – это одно из важнейших полей в лог-файле. По реферерам определяется количество посетителей на веб-сайт рекламодателя привлекает один из издателей. Если поле реферера остаётся пустым, это означает, что пользователь набрал адрес непосредственно в браузере, а не перешёл по ссылке.

    Синонимы: нет
    Все термины на букву «Р»
    Все термины в глоссарии

    Добавить комментарий