Заголовок сообщения Referrer Policy | Жизнь — это движение! А тестирование
Это перевод статьи «A new security header: Referrer Policy» Scott Helme, публикуется с разрешения автора. ©Рекомендую прокачивать английский и использовать оригинал. В конце концов, из меня такой себе переводчик, своими словами перескажу.
Также статью можно прочитать в конфлюенсе — там есть оглавление и таблички отображаются лучше, чем в блоггере.
Если включить в браузере F12 и отследить любой запрос, в разделе «Основные заголовки» (Headers — General
) мы увидим некий Referrer Policy
. Вот с ним и будем разбираться.
Чтобы получить скриншот как на картинке:
- Откройте http://users.bugred.ru
- Включите F12, вкладку
Network
- В самой системе переключитесь на другую страницу (внизу списка пользователей есть пагинация)
- Найдите этот запрос и изучите заголовки.
Заголовок
Referrer Policy
позволяет сайту контролировать значение заголовка Referer
для ссылок, ведущих с вашей страницы.Что такое Referer?
Когда пользователь переходит с одного сайта на другой, второй сайт сохраняет информацию «откуда ко мне пришли». Благодаря этому мы получаем всякие метрики типа Яндекс.Метрики или Google Analytics. И именно благодаря этой информации мы узнаем, откуда к нам приходит трафик. Вот, например, Скотт точно знает, что к нему на сайт за неделю 4000 человек пришло именно из Твиттера. Это видно из заголовка Referer:
Request Headers:…Host: scotthelme.co.ukReferer: https://twitter.com/Scott_Helme/status/760790725776830464Upgrade-Insecure-Requests: 1….
А вот так выглядит трафик в моем блоге за неделю. И эта информация также собирается из заголовка Referer:
Заголовок Referer позволяет понять, откуда к нам пришли пользователи, и это очень удобная фича. Особенно для маркетинга — стоит ли оплачивать рекламу в ФБ, ВК, Яндексе? Это недешево стоит, а оценить выхлоп можно благодаря заголовку. Вложились в рекламу и следим, сколько покупателей пришло в магазин. Так и делаем выводы, окупилась реклама или это деньги «в никуда».Заголовок Referrer Policy
Официальная информация по заголовку опубликована 26 января 2017 года, найти ее можно на сайте W3C Candidate Recommendation. Но автор решил вынести ее в свой блог, а я — в свой. Так удобнее, когда ты сам контролируешь свои статьи и не зависишь от сломавшихся ссылок. А еще у Скотта описание более понятное благодаря примерам. Именно поэтому я перевожу его статью, а не официальную документацию.
Referrer Policy — это HTTP response header, заголовок ответа. Он может содержать одно из следующих значений:
enum ReferrerPolicy {
«»,
«no-referrer»,
«no-referrer-when-downgrade»,
«same-origin»,
«origin»,
«strict-origin»,
«origin-when-cross-origin»,
«strict-origin-when-cross-origin»,
«unsafe-url»
};
Ниже я объясню каждый вариант, что именно он делает.
пустая строка
Пустая строка в заголовке Referrer Policy означает, что сайт не хочет устанавливать значение заголовка, и браузеру придется сделать это самому. Браузер может выбрать заголовок на основании, например, элемента в HTML, или атрибута referrerpolicy на элементах типа и (ссылочные теги в HTML), или на ключе rel=»noreferrer» на элементе . Использования пустую строку, вы никакого воздействия на Referer сами не делаете, оставляя все на откуп сайта.
no-referrer
Значение no-referrer говорит браузеру никогда не слать заголовок referer для запросов с твоего сайта. Это касается как ссылок на внешние ресурсы, так и на другие страницы своего сайта. Полная анонимность.
Source (откуда ссылка) | Destination (куда) | Referrer (значение заголовка) |
---|---|---|
https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | NULL |
https://scotthelme. co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | NULL |
http://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | NULL |
http://scotthelme.co.uk/blog1/ | http://example.com | NULL |
http://scotthelme.co.uk/blog1/ | https://example.com | NULL |
https://scotthelme.co.uk/blog1/ | http://example.com | NULL |
Если вы не видите отличий между ссылками, то обратите внимание на разницу HTTP и HTTPS. Автор показывает, что нет разницы, переходим мы с защищенного ресурса или нет. В других значениях заголовка эта разница будет
no-referrer-when-downgrade
Браузер НЕ будет отправлять значение referer при переходе с HTTPS на HTTP, но отправит полную ссылку при переходе с HTTP куда-то еще.Тут не важно, отличаются ли source и destination, или ведут на один и тот же сайт (кросс-ссылки внутри сайта)
Source (откуда ссылка) | Destination (куда) | Referrer (значение заголовка) |
---|---|---|
https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | NULL |
https://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/blog1/ |
http://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | http://scotthelme.co.uk/blog1/ |
http://scotthelme.co.uk/blog1/ | http://example.com | http://scotthelme.co.uk/blog1/ |
http://scotthelme.co.uk/blog1/ | https://example.com | http://scotthelme.co.uk/blog1/ |
https://scotthelme. co.uk/blog1/ | http://example.com | NULL |
same-origin
Source (откуда ссылка) | Destination (куда) | Referrer (значение заголовка) |
---|---|---|
https://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/blog1/ |
https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | NULL |
https://scotthelme.co.uk/blog1/ | http://example.com | NULL |
https://scotthelme.co.uk/blog1/ | https://example.com | NULL |
origin
Браузер всегда отображает в referer только сайт, откуда пришел запрос. Всю дополнительную информацию из URL он вырезаетSource (откуда ссылка) | Destination (куда) | Referrer (значение заголовка) |
---|---|---|
https://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/ |
http://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/ | |
https://scotthelme.co.uk/blog1/ | http://example.com | https://scotthelme.co.uk/ |
strict-origin
Аналогично origin, но данный заголовок запрещает слать информацию на HTTP, только на защищенные ссылки: HTTPSSource (откуда ссылка) | Destination (куда) | Referrer (значение заголовка) |
---|---|---|
https://scotthelme.co.uk/blog1/ | https://scotthelme. | https://scotthelme.co.uk/ |
https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | NULL |
https://scotthelme.co.uk/blog1/ | http://example.com | NULL |
http://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | http://scotthelme.co.uk/ |
http://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | http://scotthelme.co.uk/ |
http://scotthelme.co.uk/blog1/ | http://example.com | http://scotthelme.co.uk/ |
origin-when-cross-origin
Браузер отправляет полный URL на тот же сайт, и неполный (только название) на все остальныеSource (откуда ссылка) | Destination (куда) | Referrer (значение заголовка) |
---|---|---|
https://scotthelme. co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/blog1/ |
https://scotthelme.co.uk/blog1/ | https://example.com/ | https://scotthelme.co.uk/ |
https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/ |
https://scotthelme.co.uk/blog1/ | http://example.com/ | https://scotthelme.co.uk/ |
http://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | http://scotthelme.co.uk/ |
strict-origin-when-cross-origin
Аналогичноorigin-when-cross-origin
, но запрещает делать downgrade безопасности: отправляет пустоту, если пользователь переходит с HTTPS на HTTPSource (откуда ссылка) | Destination (куда) | Referrer (значение заголовка) |
---|---|---|
https://scotthelme. co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/blog1/ |
https://scotthelme.co.uk/blog1/ | https://example.com/ | https://scotthelme.co.uk/ |
https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | NULL |
https://scotthelme.co.uk/blog1/ | http://example.com/ | NULL |
http://scotthelme.co.uk/blog1/ | http://example.com/ | http://scotthelme.co.uk/ |
unsafe-url
Браузер всегда посылает полный URL, с любого сайта.Source (откуда ссылка) | Destination (куда) | Referrer (значение заголовка) |
---|---|---|
https://scotthelme.co.uk/blog1/ | https://scotthelme.co.uk/blog2/ | https://scotthelme. co.uk/blog1/ |
https://scotthelme.co.uk/blog1/ | https://example.com/ | https://scotthelme.co.uk/blog1/ |
https://scotthelme.co.uk/blog1/ | http://scotthelme.co.uk/blog2/ | https://scotthelme.co.uk/blog1/ |
https://scotthelme.co.uk/blog1/ | http://example.com/ | https://scotthelme.co.uk/blog1/ |
http://scotthelme.co.uk/blog1/ | http://example.com/ | http://scotthelme.co.uk/ |
Рекомендации
Какой именно заголовок использовать — зависит от вашего желания или выставленных требований. Но от некоторых лучше держаться подальше. Например, автор не рекомендует использовать unsafe-url, который ничего не скрывает.Аналогично, если вы подумываете взять origin или origin-when-cross-origin, автор рекомендует вместо них присмотреться к strict-origin и strict-origin-when-cross-origin. Это, по крайней мере, заткнет небольшую дыру протекающих данных о ссылающемся домене по опасному каналу HTTP.
У самого автора нет ничего секретного в URL сайта, поэтому он предпочитает использовать no-referrer-when-downgrade, чисто для сохранности данных при переходе на HTTP.
К слову, потыкав разные сайты, включая https://www.google.com/, я заметила, что значение no-referrer-when-downgrade и правда самое популярное. Практически стандарт!
PS — статью эту я нашла, пока искала материал для курса «Тестирование REST API», переводила в помощь студентам.
API Google Referrer помогает бороться с мошенничеством в мобильных сетях
Lior Goldin Jul 20, 2018Google Play Referrer — это стандартный, но очень надежный и точный способ атрибуции конверсий через Google Play (но не из магазина Android). Он позволяет поставщику атрибуции отслеживать статистику и отправлять ее параметры в магазин, а затем получать их обратно при загрузке приложения.
Но мошенники постоянно ищут новые способы перехитрить защиту – например, они обнаружили лазейку в методе Referrer API, которую можно использовать для перехвата установок.
В отличие от ботов или поведенческих аномалий, перехват установки компрометирует атрибуцию реальной установки от реального пользователя. При таком мошенничестве вредоносный код отправляет ложные «партнерские» данные в SDK поставщика измерений или атрибуции, пытаясь присвоить оплату за установку приложения себе.
Новый Google Referrer API, разработанный в сотрудничестве с нашими партнерами в Google, закрывает эту брешь, аутентифицируя данные партнера и активно блокируя внедрение поддельных партнерских данных.
Насколько эффективен будет новый Google Referrer API в борьбе с мошенничеством?
Мы видим многочисленные попытки мошенничества, направленные на платформы атрибуции в играх путем внедрения кликов после начала загрузки. Особенно часто это встречается в азиатских кампаниях.
Перехваты партнерских установок по странам
Что касается тематических категорий, то больше всех страдает финансовая отрасль, на втором месте – лайфстайл. Негативное влияние на гейминг-сферу относительно невелико, вероятно из-за более низкого в этом сегменте показателя CPI, который не так привлекателен для мошенников. Кроме того, маркетологи игровых приложений в большинстве своем — это опытные и технически подкованные специалисты, они используют сильные защитные механизмы чаще, чем их коллеги из других тематических отраслей.
Перехваты партнерских установок по категориям
Прозрачность, точность и глубокий анализ
Понимание того, какой путь проделывают ваши пользователи между нажатием на партнерскую ссылку Google и установкой вашего приложения, будет крайне важно для обнаружения и блокировки перехвата установки, это также поможет вам принимать более взвешенные решения о развитии продукта и его маркетинге.
Вот почему AppsFlyer обеспечивает комплексные отчеты о перехвате партнерских установок на дашборде Protect360 и делает новые данные в Play Store доступными для отчетов с сырыми данными.
Эти новые данные Play Store содержат:
- Строку партнерских данных (URL-адрес) установленного пакета
- Метку времени (в секундах) о моменте нажатия партнерской ссылки
- Метку времени (в секундах) о моменте начала процесса установки (загрузки)
- Повышают точность обнаружения и блокировки рекламного мошенничества.
- Предоставляют более глубокий и подробный анализ: вы будете точно знать, мошенничество какого типа было заблокировано и почему.
- Дают более четкое понимание пути пользователя: в прошлом единственными доступными моментами были время нажатия и время установки, а добавление новых моментов дает больше информации о пути клиентов мобильных приложений.
- Обеспечивают доступность информации о строке источника ссылки. Это означает, что мошенники больше не могут имитировать URL-адрес партнерской ссылки.
- Дают больше определенности за пределами показателя CTIT: стандартный анализ для поиска перехвата установок по показателю времени от нажатия до установки (CTIT) обычно ориентирован на поиск большого числа установок в течение первых 2-5 секунд после нажатия, но некоторые приложения устанавливаются медленнее, чем другие. Анализируя весь путь пользователей — нажатие, загрузка, первое открытие приложения — вы сможете принимать более обоснованные решения и настраивать свой показатель CTIT на основе поведения ваших пользователей.
About Lior Goldin
As a Partner Development Director, Lior manages AppsFlyer’s worldwide partnership with Google. Prior to joining AppsFlyer, Lior worked with leading marketers and agencies, bringing innovative marketing and advertising campaigns to life.Реферальная программа | Yandex.Cloud — Документация
Реферальная программа — программа привлечения новых клиентов Yandex. Cloud с помощью распространения реферальных ссылок. Ссылки уникальны и позволяют идентифицировать партнера. Партнер, привлекший клиента, получает процент от оплаченного клиентом потребления.
Участники программы:
- Реферер — это компания партнер, которая привлекает клиентов в Yandex.Cloud. Реферером может быть только юридическое лицо, резидент РФ.
- Реферал — это привлеченный клиент. Реферал может быть как юридическим, так и физическим лицом.
Как участвовать в программе
Чтобы стать реферером, ваш платежный аккаунт должен соответствовать следующим требованиям:
- Тип платежного аккаунта: Бизнес-аккаунт.
- Бизнес-аккаунт оформлен на юридическое лицо или ИП, резидента РФ.
- В бизнес-аккаунте выбран тип оплаты
Банковским переводом
. - Бизнес-аккаунт перешел в платное потребление, при этом стартовые гранты могут быть доступны для использования.
Чтобы стать реферером:
На сайте нажмите кнопку Стать партнёром.
Заполните форму.
После получения статуса партнера сгенерируйте реферальные ссылки в партнерском портале.
Примечание
Чтобы стать реферером, ваш платежный аккаунт должен соответствовать требованиям.
Делитесь реферальными ссылками с потенциальными клиентами.
Если клиент регистрируется по ссылке, соблюдая условия, вы получаете вознаграждение.
Требования к аккаунту реферера
Для получения статуса реферального партнера ваш платежный аккаунт должен соответствовать следующим условиям:
- Тип платежного аккаунта: Бизнес-аккаунт.
- Бизнес-аккаунт оформлен на юридическое лицо или ИП, резидента РФ;
- В бизнес-аккаунте выбран тип оплаты
Банковским переводом
. - Бизнес-аккаунт перешел в платное потребление, при этом стартовые гранты могут быть доступны для использования.
Вознаграждение за привлеченного реферала
Условия регистрации реферала
К реферальной программе могут привлекаться:
- Новые пользователи.
Новым считается пользователь, который еще не был зарегистрирован в Yandex.Cloud. - Пользователи, неактивные более 32 дней.
Неактивным считается пользователь, чей аккаунт был в статусеSUSPENDED
и не потреблял ресурсы сервисов более 32 дней.
Чтобы реферер получил вознаграждение, реферал должен:
Пройти по реферальной ссылке и зарегистрироваться в Yandex.Cloud.
Особенности регистрации по реферальной ссылке:
- Если пользователь закрыл браузер, а затем открыл ту же ссылку повторно, регистрация будет зачтена. Если же пользователь открыл URL-адрес без использования реферальной ссылки, регистрация не будет зачтена.
- Если при регистрации у пользователя отсутствовала какая-то информация (телефон или почта в Яндекс.Паспорте), то регистрация будет зачтена только после того, как пользователь внесет недостающую информацию и вернется к процессу регистрации в Yandex.Cloud.
- Если пользователь закроет вкладку и откроет консоль без использования реферальной ссылки (например, https://console. cloud.yandex.ru/), то регистрация не будет зачтена.
Дать свое согласие на то, что в течение 12 месяцев реферер будет видеть информацию о его потреблении.
Реферер будет видеть только общее потребление, совершенное рефералом. Это необходимо для обеспечения прозрачности вознаграждения.
Никаких дополнительных договоров на предоставление услуг Yandex.Cloud между реферером и рефералом не заключается.
Если условия выше не соблюдены, клиент не считается участником реферальной программы. В этом случае партнер не получает за него вознаграждение.
Сумма вознаграждения
Размер вознаграждения партнера составляет 10% от суммы продаж рефералам с учетом НДС, но не более 2 500 ₽ в месяц за одного клиента. Вы можете отслеживать потребление привлеченных вами реферальных клиентов в личном кабинете на партнерском портале.
Продолжительность вознаграждения за одного реферала
Вознаграждение за реферала выплачивается в течение 12 месяцев с момента его регистрации по ссылке реферера.
Начисление вознаграждения
Начисление вознаграждения происходит раз в месяц, когда Yandex.Cloud получает оплату потребления от реферала. Если клиент не потреблял или не оплатил ресурсы Yandex.Cloud, вознаграждение не выплачивается.
Способы получения вознаграждения
Минимальная сумма для выведения вознаграждения — 500 ₽. Получить вознаграждение можно двумя способами:
- Вознаграждение определяется как 10% от суммы продаж рефералам с учетом НДС.
Если вы применяете ОСН, рассчитанное таким образом вознаграждение будет включать НДС по ставке 20%. Мы предоставим счет-фактуру и акт с выделением суммы НДС, чтобы вы уплатили НДС в бюджет.
Если вы применяете УСН, вознаграждение не облагается НДС. - Перевести в грант и использовать для оплаты услуг Yandex.Cloud.
Выбрать способ получения вознаграждения можно в партнерском портале.
★★★★★ Smart Referer — обзор, плюсы и минусы программы, отзывы пользователей.
Описание
Это расширение автоматически скрывает реферер при смене доменов. Смена домена основана на одной и той же политике происхождения. Режим строгого режима: при включении Smart Referer будет обрабатывать разные субдомены как разные веб-сайты. Поэтому a.example.com & b.example.com не смогут видеть друг друга. В целом, это часто приводит к проблемам и приводит к незначительному или нулевому улучшению конфиденциальности, поэтому мы настоятельно рекомендуем оставить это отключенным. Дополнительная информация »Исключения: список различных исходных и целевых хостов, для которых никогда не должен быть изменен их реферер. Например, правило с Source * & Destination * .example.com будет передавать рефереры всех веб-сайтов любому ресурсу, обслуживаемому на example.com (включая его субдомены). Источники белого списка: список документов, содержащих дополнительные правила белого списка. Белый список по умолчанию пытается минимизировать влияние его расширения на повседневный веб-серфинг, обеспечивая при этом максимально возможную конфиденциальность реферера в этих условиях. Это может быть не то, что вы хотите. Неправильное поведение фальсифицированных рефереров также уже не является распространенным явлением, поэтому большинство пользователей не должны испытывать никаких проблем при полном отключении этой функции. Режим перезаписи: может использоваться для изменения того, что отправляется на сервер, вместо исходного заголовка реферера. Известно, что значение по умолчанию («Отправить URL, который вы собираетесь использовать в качестве реферера») вызывает наименьшее количество проблем на большинстве сайтов и поэтому рекомендуется. Веб-сайт не работает, что мне делать? Если веб-сайт работает неправильно Первое, что вы можете попробовать, это убедиться, что строгий режим отключен. Если проблема не решена, вы можете попробовать добавить исключение для домена, добавив источник *. & пункт назначения *. Предоставляя www.example.com доступ ко всему с помощью оригинального реферера, вы, следовательно, добавляете * .example.com в качестве источника & * в качестве пункта назначения. Если вы хотите помочь найти разумную запись в белом списке, которая решает проблему для всех, см. Запись в вики: https://tiny.cc/smart-referer-whitelist
Видео
Интерфейс
Подмена referer (реферера), зачем и кому нужно?
Если вы задаетесь вопросом как накрутить переходом с подменой реферера, то вы пришли по адресу!
Точнее вы попали по верному сайту, ваш реферер — поисковой! А как накрутить переходы с реферером? Как это делается? Для чего? Попробуем разобраться в данной статье.
Во первых давайте подумаем для чего это может быть нужно и кому!?
В большинстве случаев (95%) вы заинтересовались этим вопросом, если вы вебмастер, продаете трафик, занимаетесь арбитражем трафика, или просто крутите партнерские программы — если да, то вы найдете ответ как накрутить переходы, точнее вы его уже нашли — мы автоматизированный сервис, и такая услуга у нас есть!
Каким же бывает реферер? Можно выделить основные группы и направления такого реферера, итак начнем:
- Поисковой реферер (люди «якобы» приходят по поисковым запросам)
- Закладочный трафик
- С рекламы
- Другие сайты
- Почтовый
- Неопределенный
Теперь подробно расскажем, что есть что, и для чего требуется!
Поисковой реферер — таким видом подмены трафика (точнее подмены refere-a занимаются только вебмастера, таким способом они накручивают статистику счетчиков (самые распространенные — Яндекс метрика, лайвинтернет, хотлог и другие), основная задача — получить в статистике поисковый трафик.
Делается это очень просто, генерируются ссылки — такие же как в поисковике, например поисковый реферер с Яндекса по запросу «тестовый запрос» будет выглядеть вот так: «http://www.yandex.ru/yandsearch?clid=9582&text=тестовый%20запрос&l10n=ru»
Это обычная ссылка, которую генерирует поисковик при поиске чего либо, в нашем случае если в качестве источника посещений передать эту ссылку, то счетчик сайта будет вынужден записать данный переход как поисковой и в статистике сайта мы увидим поисковой запрос.
Таких запросов можно сделать тысячи, у нас в сервисе существуют специальные алгоритмы для автоматической генерации реферера для самых распространенных поисковиков: yandex.ru, google.ru, nigma.ru, search.qip.ru, go.mail.ru, nova.rambler.ru, google.com.ua, search.meta.ua, yandex.ua, search.bigmir.net, bing.com, yandex.com и другие!
Если Вашего поисковика нет — мы его по возможности добавим!
Закладочный трафик — по другому его называют трафик с закладок браузера. Вы добавляете понравившиеся Вам сайты в закладки браузера?
Да — да это именно те закладки, переходы с таким реферером считаются как закладочные, в качестве реферера передается не ссылка, а запрос «about» или «about:blank».
Накрутка таких переходов достаточно простая, иногда в некоторых счетчиках статистики, они могут записаться в «прочее».
Рекламные переходы — достаточно редко заказывают такую услугу, но все же его можно упомянуть в этом списке, по личному запросу мы сделаем реферер подходящий по переходам с Яндекс Рекламы (РСЯ) или же Google Adwords, подмена работает точно также как и в случае ссылочной подмены.
Генерируется реферер напоминающий ссылки из рекламы.
Другие сайты — пример подмены, вы можете увидеть на картинке справа, она ничем не отличается от подмены поискового трафика, только в этом случае в случайном порядке передаются сайты, которые якобы на вас ссылаются!
Почему «якобы»?
Потому что наличие ссылки на сайте на «Ваш сайт» не всегда обязательно, ее может быть и вовсе там нет, однако переходы с таким реферером дадут в счетчике статистике нужную информацию.
Такой вид подмены часто встречается при накрутке трафика SEO оптимизаторами, заставляя думать клиента, что на его сайт идет трафик из-за продвижения.
Мы намеренно стерли верные ссылки на скриншоте, чтобы не рекламировать чужие сайты.
Продажа трафика из 1000 городов и 200 областей России и Украины
У нас можно купить трафик из следующих городов и субъектов: Москва, Санкт-Петербург, Новосибирск, Екатеринбург, Нижний Новгород, Салехард, Казань, Дагестан, Якутия, Северная Осетия, Кабардино-Балкария, Карачаево-Черкессия, Ставрополь, Калмыкия, Астрахань, Адыгея, Челябинск, Омск, Самара, Ростов-на-Дону, Уфа, Красноярск, Пермь, Воронеж, Волгоград, Краснодар, Саратов, Тюмень, Тольятти, Ижевск, Барнаул, Ульяновск, Иркутск, Хабаровск, Белгород, Курск, Орел, Липецк, Тула, Брянск, Калуга, Смоленск, Рязань, Тамбов, Калининград, Псков, Новгород, Тверь, Владимир, Пенза, Мордовия, Чувашия, Оренбург, Йошкар-Ола, Иваново, Кострома, Киров, Удмуртия, Курган, Сыктывкар, Мурманск, Карелия, Вологда, Архангельск, Ханты-Мансийск, Томск, Кемерово, Алтай, Тыва, Хакасия, Бурятия, Чита, Благовещенск, Биробиджан, Владивосток, Магадан, Южно-Сахалинск, Камчатский край, Ингушетия, Чечня, Ярославль.
Также в нашей системе доступен трафик из других стран и городов — более 1000 городов и 30 видов разных стран.
Полный список городов и стран находится на странице статистики гео.
Как подменить почтовый реферер
Почтовый реферер — очень частый вид подмены переходов, которым занимаются спам-рассыльщики, как это выглядит?Допустим вы заказываете спам-рассылку на каком-то сайте, но как вы проверите, сколько переходов было с рассылки на ваш продукт/сайт?
Верно — вы будете смотреть статистику посещений по своему счетчику, а именно переходы из mail.ru, Яндекс почты и других..
Именно такие переходы с легкостью можно подделать используя наш сервис, и никто не сможет проверить их реальность!
Очень часто встречаются люди, которые так, имитируют переходы с таким почтовым реферером, тем самым показывая «работоспособность» своих услуг.
Конечно же владелец сайта, который заказывает такие спам-рассылки, догадается что люди ничего не заказывают — боты которые посещают его сайт, ничего не будут писать и не потратят деньги — но это уже другая услуга, если услуга пользуется спросом — значит она популярна, и ей пользуются.
Прочий вид — часто, к таким видам относят трафик, который счетчик не смог отнести к типам выше, например это могут быть (не всегда) переходы из почтовых клиентов по типу скайпа, icq, вибер и других.
Либо это переходы, которые использовали хитрые связки редиректов (множественные) и другие переходы.
Такой вид статистики накрутить невозможно, так как он почти никому не нужен, и его никто детально не изучал на предмет накрутки.
Больше всего интересны подмены описанные выше.
Если вам нужна качественная работа, трафик с подменой по одному из направлений описанных в данной статье — регистрируйтесь, мы будем рады Вам как нашему клиенту и с радостью проконсультируем!
Посмотрите видео и у вас не останется сомнений
Вам требуются переходы, клики или просто трафик? Регистрируйся в сервисе Go-ip.ru и заказывай трафик прямо сейчас.
Сервис Go-ip — это мощный функционал, с возможностью самостоятельно настраивать необходимые действия на сайте.
В сервисе можно настроить трафик с кликами по рекламе, баннерам, и задать нужные действия для любых целей и задач.
Сервис Go-ip имеет более пятидесяти специальных команд и функций, которые позволяют выполнять различные действия в браузере.
К примеру, можно выполнять регистрации, имитировать ввод текста в поля, шевелить мышкой, отмечать галочки и кликать по любым объектам на сайте.
Ежесуточно в сервисе насчитывается более 50 000 уникальных хостов, которые удовлетворят любую потребность.
Также в сервис имеется мощный функционал по настройке расписания показов, широкий выбор геотаргетинга, удобная панель управления, статистика переходов и многое другое. Присоединяйся к нам и работай с помощью биржи трафика Go-ip.ru.
Реферал определение | Что такое Реферал термины
Что такое реферал
Реферал – пользователь, привлеченный в интернет-проект по рекомендации другого участника (реферера). За каждого привлеченного реферала реферер получает вознаграждение. Рефералы являются участниками реферальной программы, то есть могут сами приглашать новых пользователей и зарабатывать на этом.
“Прямой реферал — зарегистрировался непосредственно по ссылке издателя.
Косвенный реферал — зарегистрировался по ссылке прямых или косвенных рефералов.”
Реферал – это участник партнерской программы, зарегистрированный по ссылкам других пользователей. Например, вы регистрируетесь на сайте, и система предоставляет уникальную ссылку с идентификатором. Пользователь, который перейдет по ней и зарегистрируется в сервисе, будет вашим рефералом. Реферал (в переводе с английского referral — «направление») — это пользователь реферальной программы маркетинга, который зарегистрировался по чьей-то рекомендации (ссылке). Реферальный маркетинг – мотивация существующих клиентов компании рекомендовать её услуги своим друзьям, коллегам и подписчикам. Предложение зарегистрироваться приходит от существующего клиента с реферальной ссылкой. В ней содержится идентификатор (учетная запись) клиента, который выслал ссылку. Новый клиент, зарегистрировавшийся по ней, и будет рефералом. Тот, кто выслал предложение – рефери, реферер, аффилиант, спонсор (встречаются разные термины).
Реферал определение
Реферал – это пользователь, зашедший на страницу по вашей реферальной ссылке и зарегистрировавшийся там. Причем, реферальные программы подразумевают хранение информации о заходе по партнерской ссылке на протяжении длительного периода, часто это 1 год. То есть, если человек перейдет по вашей ссылке и не станет регистрироваться, но после этого снова зайдет на сайт на протяжении года и зарегистрируется – он все равно станет вашим рефералом.
Реферал термин
Реферальные маркетинговые стратегии применяются многими компаниями. От маленьких начинающих интернет-магазинов, до брендов с мировыми именами: Oriflame, Uber, кинокомпания 20th Century Fox, Ecco, Webmoney, Nokia, Ozon.ru, авиакомпания S7 Airlines, Dropbox и многие другие. Рефералы – возможность увеличить клиентскую базу, поднять продажи, получить постоянных и лояльных клиентов. Стань эффективным интернет-маркетологом — запишись к нам на курсы! Школа Интернет Маркетинга Онлайн.
Direct трафик в Google Analytics — причины возникновения и как его уменьшить
Если ваш direct трафик Сеансы, когда пользователь ввел URL сайта в адресной строке или использовал закладку выше 30%, не спешите открывать шампанское и отмечать потрясающую узнаваемость компании. Вполне возможно, что Google Analytics определил в direct трафик посещения сайта, которые на самом деле к нему не относятся.
Почему так происходит? Причины могут быть техническими (обрывы сессий, редиректы и т. д.) и технологическими (переходы на сайт из мобильных приложений, email, мессенджеров и т.д.).
К какой проблеме это приводит? Невозможно правильно оценить эффективность источников трафика, которые ошибочно записываются в direct.
В этой статье вы узнаете:
Причины, по которым GA определяет сессии в direct трафик
Google Analytics ищет информацию об источниках трафика в следующей последовательности:
- Сначала GA проверяет наличие Adwords/DoubleClick тегов ( gclid Параметр автоматической пометки AdWords. Добавляется в URL целевой страницы, когда пользователь нажимает на объявление / gclsrc Параметр автоматической пометки DoubleClick Search ).
- Затем — наличие
UTM-меток
Переменная, которая добавляется в URL и позволяет системе веб-аналитики получить дополнительную информацию об источнике трафика
(
UTM_source/UTM_medium
и т.д.). Подробнее о UTM-метках читайте в нашей статье. - После ищет HTTP referrer В протоколе HTTP один из заголовков запроса клиента. Содержит URL источника запроса .
- И наконец, Google Analytics пытается идентифицировать пользователя по clientID или userID, проверяя совпадение за последние 4 часа, и привязать данные о хите к последней сессии пользователя. Например, пользователь перешел на сайт из рекламного объявления и через 2 часа купил товар в офлайн-магазине. Если данные о покупке отправляются в Google Analytics через Measurement Protocol и пользователя удается распознать по userID, хит (совершенная транзакция) будет засчитан в последнюю онлайн-сессию пользователя, у которой уже есть источник трафика (в нашем примере — google/cpc).
Чтобы определить источник трафика, достаточно одного из этих параметров. Если ничего из перечисленного не найдено, GA записывает источник трафика — direct.
Детальная схема обработки данных описана в справке GA.
По нашему опыту, в крупных проектах в direct попадает до 15% сессий, которые на самом деле к нему не относятся. Причины происходящего можно условно разделить на три группы: сессии, при которых не передается реферер, обрывы сессий и другое.
Не передается реферер
HTTP Referer — в протоколе HTTP один из заголовков запроса клиента. Содержит URL источника запроса. Если перейти с одной страницы на другую, то referer второй страницы будет содержать адрес первой страницы.
Реферер не передается в таких случаях:
- Переходы по ссылкам из оффлайновых документов: PDF, Word, Power Point и т.д.
- Переходы из мобильных и стационарных приложений: Skype, Viber, Facebook, VK, Google Search и т.д.
- Переходы из Email: Microsoft Outlook, Thunderbird и т.д.
- Отправка данных по Measurement Protocol без указания source/medium.
- Редиректы без передачи HTTP заголовка или UTM-меток в ссылке. Например, пользователь
зашел по ссылке site.com, но система перенаправила его на site.ru.
Если при редиректе не передавать HTTP заголовок (в т.ч. реферер, который привел
посетителя на сайт, например, facebook.com) или UTM-метку в конечной ссылке
(
google.ru/?UTM_source=facebook&UTM_medium=cpc
), то данный трафик будет попадать в direct. Чаще всего эта ошибка возникает, если вы делаете редиректы на стороне клиента (с помощью javascript). - Переходы c HTTPS на HTTP страницы (согласно п. 5.5.2 в стандартах работы Web). Например, если у вас сайт на HTTP, то переходы без UTM-меток c https://www.youtube.com/ будут засчитываться в direct, потому что зашифрованный протокол передачи данных HTTPS не передает реферер.
- Посетитель включил настройки приватности браузера (режим инкогнито) и дополнения для блокировки скриптов вроде ScriptSafe (установить можно здесь) и других.
- Ошибки в коде. Иногда ошибки в скриптах могут обновлять куки, и этот трафик
будет записываться в direct. Также при указании в коде ссылки
<а href=..>
атрибута‘rel=noreferrer’
реферер передаваться не будет. - Ошибки, когда браузер не передает реферер. Например в IE8 теряется реферер при
использовании редирект метода
Javascript:location.href
иMeta refresh — 0
. Также Internet Explorer теряет реферер, когда пользователь нажимает на ссылку, которая использует JS метод window.open или когда пользователь нажимает на линк, вставленный во Flash приложение. - Неправильная UTM-разметка кампании (например, UTMSource вместо UTM_source). Если у ссылки есть UTM-метка, то GA игнорирует реферер. В тех случаях, где разметка ссылки не соответствует справке, визиты будут записывать в direct.
Обрывы сессии
Пользовательские сессии могут обрываться в следующих случаях:
- Отсутствие GA/GTM кода на посадочных страницах сайта. При переходе с посадочной страницы без GA кода на следующую страницу вашего сайта в реферер запишется собственный URL и UTM-меток уже не будет. GA запишет эту сессию в direct (если собственный домен добавлен в «Список исключаемых источников перехода») или в referral (если не добавлен).
- Авторизация через социальную сеть с полным переходом на нее вместо авторизации через всплывающее окно.
- Медленно загружается код GA — пользователь переходит на следующую страницу сайта до загрузки кода.
- Отправка хита весом более 8 кбайт на посадочной странице. Хит не будет отправляться в GA, соответственно сессия будет обрываться.
- Некорректная настройка кросс-доменного отслеживания.
Другие причины, которые искажают данные по direct трафику
Посещения сайта сотрудниками компании. Их можно исключать по IP адресам, специальным cookies на корпоративных/промежуточных страницах, с помощью расширений в браузерах или фильтров в Google Analytics.
Посещения сайта ботами. Найти IP-адреса ботов можно в логах сайта или с помощью OWOX BI Pipeline, собрав данные об активности на сайте в Google BigQuery. Вычислять ботов рекомендуем:
- По поведению на сайте. Например, время визита до 2 секунд, отсутствие транзакций, высокий показатель отказов и т. д.
- По User Agent (браузеры, провайдеры, локация, устройства). Например, один провайдер (site.ru), один регион (Москва, Россия).
Краткие рекомендации по поиску проблем
Определив проблемы с direct трафиком, вы сможете исправить статистику по источникам трафика и, соответственно, точнее оценивать ROAS.
Как решить проблемы с передачей referrer:
- Проставить UTM-метки на всех ссылках (как размечать кампании, описано в статье «Что такое UTM-метки и как их применять»).
- Создать пользовательский параметр уровня хита и записывать в него значение referrer, а потом анализировать данные в специальных отчетах.
Как найти проблемы с обрывами сессий:
- С помощью консоли разработчика и GA debugger.
- С помощью записей сессий в Google Tag Assistant.
- Проверить наличие GA/GTM кода на страницах сайта, используя Screaming Frog или другие сервисы.
Мы подготовили наглядное руководство, как найти проблемы с direct трафиком, и готовы поделиться. Укажите email, на который вам его отправить.
Использованные инструменты
Заголовок Referer: проблемы конфиденциальности и безопасности — Веб-безопасность
С HTTP-заголовком Referer связаны риски конфиденциальности и безопасности. В этой статье они описаны и даны советы по снижению этих рисков.
Заголовок Referer
(sic) содержит адрес запроса (например, адрес предыдущей веб-страницы, с которой переходили по ссылке на текущую запрашиваемую страницу, или адрес страницы, загружающей изображение, или другой адрес). ресурс). У этого есть много довольно невинных применений, включая аналитику, ведение журнала или оптимизированное кэширование.Однако существуют более проблемные способы использования, такие как отслеживание или кража информации, или даже просто побочные эффекты, такие как непреднамеренная утечка конфиденциальной информации.
Например, рассмотрим страницу «сброса пароля» со ссылкой на социальную сеть в нижнем колонтитуле. Если по ссылке переходили, то в зависимости от того, как информация была передана, сайт социальной сети может получить URL-адрес для сброса пароля и по-прежнему сможет использовать совместно используемую информацию, что может поставить под угрозу безопасность пользователя.
По той же логике изображение со стороннего сайта, встроенное в вашу страницу, может привести к утечке конфиденциальной информации третьему лицу.Даже если безопасность не скомпрометирована, информация может быть не тем, чем пользователь хочет поделиться.
Большая часть этого риска может быть уменьшена за счет разумного проектирования приложений. Разумное приложение устранит такие риски, создав одноразовые URL-адреса для сброса пароля или объединив их с уникальным токеном пользователя. Риск также можно снизить, передав конфиденциальные данные более безопасными способами.
По возможности следует использовать POST
, а не GET
, чтобы избежать передачи конфиденциальных данных в другие места через URL-адреса.
Вы всегда должны использовать HTTPS для своих сайтов. Это дает много преимуществ в плане безопасности, в том числе тот факт, что сайты HTTPS никогда не будут передавать информацию о реферере на сайты, не использующие HTTPS. Этот совет менее актуален сейчас, когда большая часть Интернета использует HTTPS, но все же заслуживает внимания.
Кроме того, вам следует рассмотреть возможность удаления любого стороннего контента (например, виджетов социальных сетей, встроенных в
) из защищенных областей вашего веб-сайта, таких как страницы сброса пароля, формы оплаты, области входа в систему и т. Д.
Вы также можете снизить такие риски, используя:
- Заголовок
Referrer-Policy
на вашем сервере, чтобы контролировать, какая информация отправляется через заголовокReferer
. Например, директиваno-referrer
полностью опускает заголовок Referer. - Атрибут
referrerpolicy
в элементах HTML, которые могут привести к утечке такой информации (например,no-referrer
, чтобы полностью остановить отправку заголовкаReferer
. - Для атрибута
rel
установлено значениеnoreferrer
для элементов HTML, которые могут привести к утечке такой информации (например,noreferrer
для получения дополнительной информации. - Техника выхода из страницы.
Серверные фреймворки, заботящиеся о безопасности, как правило, имеют встроенные средства защиты от таких проблем, например:
Было бы разумно написать набор требований к безопасности и конфиденциальности для вашей проектной группы (групп), которые определяют использование таких функций для снижения связанных рисков.Вам следует заручиться помощью эксперта по веб-безопасности, чтобы написать эти требования и рассмотреть как потребности пользователей, так и их благосостояние, а также другие вопросы, такие как политика и регулирование, применяемые законодательством, таким как Общий регламент ЕС по защите данных (GDPR).
Как работает HTTP-реферер
HTTP-реферер (также называемый HTTP-реферером) — это дополнительное поле заголовка HTTP, которое распознает адрес веб-страницы (то есть унифицированный идентификатор ресурса или IRI), подключенный к запрашиваемому ресурсу.Проверяя реферер, новая веб-страница может определить, откуда был инициирован исходный запрос.
Как правило, такие ситуации обычно означают, что как только любой пользователь щелкает гиперссылку на веб-странице, браузер пересылает запрос на сервер, содержащий адрес назначения веб-страницы. Включение в такие запросы обычно включает поле реферера, которое показывает последнюю страницу, которую посетил пользователь перед тем, как щелкнуть новую ссылку.
Как работает HTTP-реферер
HTTP-реферер предоставляет услуги заголовка реферера, который передает данные с прежней веб-страницы на новый веб-сайт, который пользователь в настоящее время просматривает.Он просто относится к любому источнику в Интернете, ответственному за привлечение посетителей и посещение веб-сайта. Типичные примеры включают партнерские ссылки, маркетинговые кампании по электронной почте, ссылки, встроенные в программное обеспечение, ссылки с других веб-сайтов, онлайн-рекламу, поисковые системы, социальные сети и многое другое.
Каждый раз, когда пользователь посещает веб-сайт, одной из важных записываемых данных является информация о предыдущих веб-страницах. Эти сведения обычно представлены в виде URL-адреса страницы, например последней посещенной страницы перед выбором ссылки на новый веб-сайт.
Идея использования реферера HTTP заключается в предоставлении полезной информации, относящейся к реферальной странице, а также к ссылке, по которой щелкнули для доступа к вашему веб-сайту. Журнал, содержащий такую информацию, называется журналом реферера. Технически, когда термин «реферер» используется веб-разработчиком, он явно относится к онлайн-ресурсам, включая сайты или услуги, найденные в журнале рефереров.
Почему важен HTTP-реферер?
Информация, предоставленная HTTP-реферером, позволяет лучше анализировать, откуда исходит трафик веб-сайта. Кроме того, он также дает представление о том, что работает для веб-сайта с точки зрения маркетинга и какой маркетинговый подход действует в настоящее время. Как правило, информация, полученная от реферера HTTP, помогает большинству веб-сайтов делать лучший выбор, когда дело доходит до разработки стратегии.
Как HTTP-рефереры используются для отслеживания активности пользователей?
Владельцы веб-сайтов часто хотят знать, откуда приходят их посетители, и могут решить отслеживать путь своего пользователя. HTTP-реферер предлагает уникальный подход к сообщению владельцам веб-сайтов как полезных, так и менее полезных ссылок.
Как только пользователь, подключенный к Интернету, щелкает ссылку в браузере, он загружает выбранную веб-страницу, а также сообщает новой веб-странице, где пользователь посещал последний раз. Таким образом, он содержит всю информацию, относящуюся к прошлым веб-сайтам.
HTTP-реферер также задействован, когда веб-страница загружает свое содержимое. Скажем, если веб-страница содержит рекламу или скрипт отслеживания, пользовательские браузеры также предоставляют рекламодателю или сети отслеживания информацию о просматриваемой в данный момент странице. Кроме того, веб-ошибки, представляющие собой файловый объект, размещенный на веб-страницах, используют возможности реферера HTTP для отслеживания пользователей.
Мера, которая может быть предпринята для защиты конфиденциальности
HTTP-реферер остается распространенным и мощным инструментом, способным указать, на каком веб-сайте была размещена ссылка, по которой текущий посетитель щелкнул, чтобы перейти на ваш сайт. Хотя это остается полезным для веб-дизайнеров и специалистов по поисковой оптимизации, которые стремятся привлечь больше нужной аудитории и посетителей, некоторым пользователям неудобно, что их отслеживают.
Есть несколько мер, которые необходимо предпринять для защиты себя от отслеживания с помощью HTTP referer.Но как это сделать?
Еще один шаг к большей конфиденциальности и защите начинается с настроек безопасности в браузере пользователя. В настройках безопасности можно отключить реферер HTTP, чтобы ограничить его возможности. После его выключения доступ к URL-адресу с помощью HTTP-реферала может быть предоставлен только в том случае, если реферер может быть установлен.
Еще одним шагом к снижению риска, связанного с HTTP-реферером, является разумный дизайн приложений. Использование практического приложения повышает безопасность, делая URL-адреса для сброса пароля функциональными только для одноразового использования.
Также важно привлекать только те сайты, которые всегда используют HTTPS. Веб-сайты с HTTPS предлагают несколько преимуществ безопасности, в том числе тот факт, что такие веб-сайты никогда не будут передавать данные реферера на сайты без HTTPS. Хотя эта концепция оказывается менее полезной в этом контексте, поскольку большинство веб-сайтов теперь используют HTTPS, но ее стоит отметить.
Кроме того, пользователям не следует использовать сторонний контент или виджеты (например, виджеты социальных сетей) в менее защищенных областях или на веб-сайтах. Например, области входа в систему, формы оплаты, страницы сброса пароля и т. Д.
В заключение
Использование HTTP-реферера упрощает задачу для некоторых владельцев веб-сайтов, которые могут рассмотреть возможность увидеть, с каких страниц приходят посетители. Использование определенных веб-сайтов может быть связано с другими веб-сайтами, особенно если вы, вероятно, перейдете по ссылке, отображаемой на странице. Тем не менее, конфиденциальность и использование данных всегда являются важными причинами для множества пользователей, и теперь вы знаете, что могут быть предприняты конкретные шаги для повышения вашей общей безопасности, а также для ограничения действий HTTP-реферера.
Узнайте больше с Echo Analytics Group
Echo Analytics Group — это аналитическая компания с полным спектром услуг, предоставляющая услуги, продукты, обучение и технологии как государственным, так и частным предприятиям. Echo Analytics Group обучила тысячи специалистов по разведке лично и в Интернете. Мы также поставляем продукты и услуги мирового класса множеству предприятий по всему миру.
Чтобы узнать больше о Echo Analytics Group, свяжитесь с нами, заполнив нашу онлайн-форму или отправив нам электронное письмо по адресу info @ echoanalyticsgroup.com.
Чтобы записаться на курс, изучите нашу Echo Academy!
Мы с нетерпением ждем возможности связаться с вами.
Internet Explorer не отправляет заголовок Referer в незащищенных ситуациях
Сводка
При связывании одного документа с другим в Internet Explorer 4.0 и более поздних версиях заголовок Referer не отправляется, если ссылка ведет со страницы HTTPS на страницу без HTTPS. Заголовок Referer также не будет отправлен, если ссылка идет от протокола, отличного от HTTP (S), такого как file: //, на другую страницу.
Дополнительная информация
Заголовок Referer — это стандартный HTTP-заголовок в форме «Referer:
Однако Internet Explorer не будет отправлять заголовок Referer в ситуациях, которые могут привести к случайной отправке защищенных данных на незащищенные сайты. Например, Internet Explorer не будет отправлять заголовок Referer для каждой из следующих гиперссылок из URL одного документа в URL другого документа:
javascript: somejavascriptcode -> http://example.microsoft.com
file: // c: \ alocalhtmlfile.htm -> http: // example.microsoft.com
https://example.microsoft.com -> http://www.microsoft.com
Это предотвращает непреднамеренную отправку имен локальных файлов на веб-серверы при связывании локального содержимого с веб-сайтами, которые могут отслеживать такую информацию. Кроме того, многие защищенные (HTTPS) веб-серверы хранят защищенную информацию, такую как данные кредитной карты, в URL-адресе во время запроса GET к серверному приложению CGI или ISAPI. Эта информация может быть непреднамеренно отправлена в заголовке Referer при подключении с сервера «https: //» к серверу «http: //» в другом месте в Интернете.Internet Explorer пытается предотвратить эту плохую практику, не отправляя заголовок Referer при переходе с URL-адреса HTTPS на URL-адрес, отличный от HTTPS.
8 причин, по которым данные вашего реферера не раскрывают всей истории • BL.INK
Как наша аудитория нашла эту страницу?
Это один из самых важных вопросов любого специалиста по цифровому маркетингу. Если вы знаете, откуда взялась ваша аудитория, вы можете использовать эту информацию для повышения вовлеченности.
Естественное начало — поиск исходных данных о трафике. Однако обращение к данным о трафике может быть не таким надежным, как вы думаете. Особенно, когда вы пытаетесь оценить свои данные на нескольких платформах отчетности.
Чтобы лучше понять это, давайте начнем с самого начала: как изначально отслеживался реферальный трафик в Интернете? HTTP Referer — это поле заголовка HTTP, которое определяет адрес веб-страницы, с которой была сделана ссылка.
Примечание: заметили что-то не так в последнем предложении? Это не опечатка. Еще в первые дни Интернета произошла ошибка (изначально неправильно написано «реферер» вместо реферера), что вызвало некоторые проблемы в дальнейшем. Веб-разработчикам сегодня все еще приходится использовать слово «referer» с ошибкой в написании для поиска трафика.
Заголовок реферера передает информацию о предыдущей веб-странице на новую веб-страницу. Если пользователь переходит со страницы A на страницу B, тогда URL-адрес страницы A будет передан в заголовке, и вы будете знать, что трафик пришел со страницы A.
Звучит достаточно просто. Так почему же вы не получаете полного представления о переходящем трафике?
Причины, по которым ваша панель управления может не отображать аналитику рефереров- Ссылки с https никогда не отправят реферер на веб-страницу http. Для большинства запросов https-to-http детали реферера заблокированы.
- Все ссылки, использующие метод JavaScript window.open, теряют все источники перехода в Internet Explorer (IE).
- Мобильные приложения не отправляют ссылки.Приложения для смартфонов не могут передавать информацию о «ссылающейся странице» в аналитику вашего сайта. Так что статистика прямого трафика может быть завышена.
- У пользователей включена функция «без рефереров». Пользователи могут отключить возможность передачи реферальной информации через свои браузеры.
- Ссылки, встроенные в PDF, документ Word или другие файлы, отличные от HTML, не будут отправлять источники перехода. Они регистрируются не как источники перехода на веб-сайты, а как отдельные приложения.
- Ссылки, поступающие из электронной почты или мгновенного сообщения, не будут отправлять рефереры.
- Ссылки, введенные непосредственно в браузере или скопированные и вставленные из другого источника, не будут отправлять рефереры.
- Пользователи, использующие VPN или брандмауэр, не будут отправлять рефереры.
Лучший способ — убедиться, что вы используете параметры отслеживания в своем URL. Параметры отслеживания, известные как коды UTM в Google Analytics, — это теги, которые вы добавляете в конец целевого URL, чтобы вы могли отслеживать клики по этой ссылке на панели инструментов аналитики.Используя такие теги, как «источник», «среда» и «кампания», вы можете ответить на ключевые вопросы о своем трафике, не полагаясь на данные реферера.
Чтобы узнать больше о кодах UTM и передовых методах, ознакомьтесь с разделом «Как использовать коды UTM».
Что делать, если я не использую Google Analytics? Коды отслеживанияне являются эксклюзивными для Google Analytics. На других платформах аналитики есть собственный способ добавления параметров отслеживания к вашим ссылкам.Понимание методов отслеживания вашей платформы является ключом к получению информации, поэтому убедитесь, что вы понимаете параметры и используете их в своем целевом URL. Вам больше никогда не придется полагаться на рефереров!
Что делать, если у меня нет аналитической платформы?Нет проблем. Bl.INK включает расширенную аналитику на панели управления ссылками. Bl.INK сообщает необработанные данные о кликах для каждой ссылки только с двумя исключениями: известные боты фильтруются (то есть они самоидентифицируются), а IP-адреса центров обработки данных фильтруются.Данные Bl.INK максимально приближены к трафику кликов людей, поэтому ваша команда может разрезать данные так, как вы считаете нужным.
Имея правильные параметры отслеживания и платформу аналитики, вы настроены на более глубокое понимание своей аудитории и на пути к еще большему вовлечению.
Мини-руководство по HTTP referer
В заголовке HTTP есть поле с именем Referer
, которое должно предоставить реферер текущей страницы, к которой осуществляется доступ.В этом посте мы познакомимся с использованием поля HTTP-реферала.
В сети, когда пользователь посещает веб-страницу, он должен быть откуда-то. Это место обычно упоминается как s referer. Эта информация очень важна для некоторых операторов веб-сайтов и владельцев серверов, поскольку они хотят знать, откуда они получают трафик, и это помогает им предоставлять более качественные услуги потенциальным целевым пользователям.
В заголовке запроса HTTP есть поле Referer , которое может быть установлено на URL-адрес реферера, указывающий источник посещения.
Это необязательное поле, что означает, что иногда вы не видите значение, установленное для этого поля в HTTP-запросе. Одна забавная особенность этого поля заключается в том, что в названии поля есть опечатка. Правильное английское слово — Referrer вместо Referer , но когда это было окончательно доработано в стандарте RFC, похоже, никто не обнаружил, что отсутствует r . Позже, после того, как стандарт был окончательно доработан, люди должны следовать этой неправильной конвенции.
Как упоминалось ранее, Referer является необязательным полем в HTTP-запросе, поэтому в некоторых случаях Referer будет отправлен и опущен.Обычно, когда пользователь вводит URL-адрес в адресной строке браузера или открывает ссылку из закладки, Referer не отправляется.
По умолчанию в следующих трех случаях будет отправлено поле Referer.
- Когда пользователь нажимает ссылку на веб-странице
- Когда пользователь отправляет форму (нажмите «Отправить»)
- При загрузке статического ресурса, такого как изображение, файл JavaScript, CSS.
В приведенных выше случаях браузер установит поле Referer в качестве URL-адреса текущей веб-страницы и поместит его в заголовок HTTP-запроса. Кроме того, JavaScript также предоставляет document.referrer
для проверки Referer.
Поле Referer фактически сообщает целевому веб-серверу исходный URL-адрес перед посещением текущей страницы, это может использоваться для отслеживания пользователя. Типичное использование этого поля — блокировка загрузки статического ресурса, такого как изображение, внешним веб-сайтом.Этого можно достичь, проверив Referer, если Referer с внешнего веб-сайта, и сообщив об ошибке, в противном случае разрешите загрузку ресурса.
Но в случаях, когда мы не хотим раскрывать конфиденциальную информацию, мы можем не отправлять Referer. Один из примеров: при доступе к некоторым веб-страницам из интрасети мы не хотим, чтобы внешние пользователи знали о внутренней архитектуре или конфигурации домена интрасети. Учитывая вышеизложенное, все современные браузеры предоставляют владельцам веб-сайтов несколько способов изменить поведение Referer по умолчанию.
HTML предоставляет атрибут с именем rel , которому можно присвоить значение noreferrer , чтобы блокировать отправку информации реферера, когда пользователь щелкает ссылку. Этот атрибут применим к , , области и образуют тег в HTML.
xxx
Запрос на указанный выше целевой URL не будет иметь Referer, установленного в заголовке запроса.
Атрибут relможет быть установлен только для одного элемента HTML, и он может только контролировать, отправлять ли Referer или нет.Из-за этих ограничений W3C предлагает более мощную настройку — политику реферера.
Существует 8 разрешенных значений для политики реферера.
enum ReferrerPolicy {
"",
"без реферера",
"no-referrer-when-downgrade",
"то же происхождение",
"источник",
"строгое происхождение",
"происхождение-при-перекрестном происхождении",
"строгое происхождение при перекрестном происхождении",
"небезопасный URL"
};
Политика реферера может быть установлена в нескольких разных местах.
1. HTTP-заголовок
Когда веб-сервер отправляет веб-страницу в браузер, он может сообщить браузеру о политике реферера в заголовке.
Политика реферера: origin
2. метатег
В заголовке HTML-страницы также можно установить метатег.
3. Атрибут referrerpolicy
В элементе HTML также можно установить атрибут referrerpolicy. Это применимо к тегам a, area, img, iframe и link.
xxx
Последний совет. Есть также традиционный способ, принятый крупными компаниями, такими как Google и Facebook, для блокировки отправки HTTP Referer. то есть установите href на внутреннюю веб-страницу с URL-адресом перенаправления. Это может эффективно избежать отправки Referer при доступе к другому URL-адресу.
com"> Example.com
Ссылка: http: // www.ruanyifeng.com/blog/2019/06/http-referer.html
Новая политика реферера по умолчанию для Chrome: strict-origin-when-cross-origin
Адвокат разработчиков в Google, работающий над конфиденциальностью и безопасностью Chrome
Перед тем, как мы начнем:
- Если вы не уверены в разнице между «сайтом» и «происхождением», ознакомьтесь с разделом «Понимание» «тот же сайт» и «то же происхождение».
- В заголовке
Referer
отсутствует буква R из-за неправильного написания в спецификации.В ЗаголовокReferrer-Policy
иreferrer
в JavaScript и DOM написаны правильно.
Сводка
- Браузеры развиваются в сторону политик рефереров по умолчанию, повышающих конфиденциальность, чтобы обеспечить хорошее откат, если для веб-сайта не задана политика.
- Chrome планирует постепенно включить
strict-origin-when-cross-origin
в качестве политики по умолчанию в 85; это может повлиять на варианты использования, основанные на значении реферера из другого источника. - Это новое значение по умолчанию, но веб-сайты по-прежнему могут выбирать политику по своему усмотрению.
- Чтобы опробовать изменения в Chrome, включите флаг на
chrome: // flags / # уменьшенный-referrer-granularity
. Вы также можете проверить это демо к увидеть изменение в действии. - Помимо политики реферера, способ работы браузеров с реферерами может измениться, поэтому следите за Это.
Что меняется и почему?
HTTP-запросы могут включать дополнительный Referer
заголовок, который указывает origin или URL-адрес веб-страницы , с которого был сделан запрос. Политика рефералов
заголовок определяет, какие данные
доступен в заголовке Referer
, а для навигации и фреймов в целевом document.referrer
.
Точно определяется, какая именно информация отправляется в заголовке Referer
в запросе с вашего сайта.
установленным вами заголовком Referrer-Policy
.
Если политика не задана, используется браузер по умолчанию. Веб-сайты часто подчиняются браузеру дефолт.
Для навигации и фреймов данные, представленные в заголовке 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
предлагает больше конфиденциальности . С этой политикой только
origin отправляется в заголовке Referer
запросы из разных источников.
Это предотвращает утечку личных данных, которые могут быть доступны из других частей полного URL-адреса, таких как путь и строка запроса.
Referer отправил (и document.referrer) для запроса на другой источник, в зависимости от политика.Например:
Запрос на другое происхождение, отправленный с https: //site-one.example/ stuff / detail? Tag = red на https: // сайт-два.пример /…:
- С
no-referrer-when-downgrade
: Referer: https: //site-one.example/ stuff / detail? Tag = red . - С
strict-origin-when-cross-origin
: Referer: https: //site-one.example/.
Что осталось прежним?
- Как
no-referrer-when-downgrade
,strict-origin-when-cross-origin
is secure : no referrer (ЗаголовокReferer
иdocument. referrer
) присутствует, когда запрос сделан с HTTPS origin (безопасный) в HTTP (небезопасный).Таким образом, если ваш сайт использует HTTPS (если нет, сделайте это приоритет), URL-адреса вашего веб-сайта не будут протекать без HTTPS запросы — потому что любой в сети может их видеть, поэтому ваши пользователи могут человек-посередине-атаки. - В пределах того же источника значение заголовка
Referer
является полным URL-адресом.
Например: Запрос с одинаковым происхождением, отправленный с https: //site-one.example/ stuff / detail? Tag = red на https: //site-one.example/…:
- С
strict-origin-when-cross-origin
: Referer: https: // site-one.пример / штука / деталь? tag = красный
Какое влияние?
На основе обсуждений с другими браузеры и собственный Chrome Эксперименты, проведенные в Chrome 84, , видимые пользователем поломки, как ожидается, будут ограничены .
Серверное ведение журнала или аналитика, которые полагаются на доступный полный URL-адрес реферера, вероятно, будут пострадали из-за снижения детализации этой информации.
Что вам нужно сделать?
Chrome планирует начать развертывание новой политики рефереров по умолчанию в 85 г. (июль 2020 г., бета-версия, август 2020 для стабильной).Смотрите статус в статусе Chrome Вход.
Понять и обнаружить изменения
Чтобы понять, что на практике меняет новое значение по умолчанию, вы можете проверить это демо.
Вы также можете использовать эту демонстрацию, чтобы определить, какая политика применяется в запущенном вами экземпляре Chrome.
Проверьте изменение и выясните, повлияет ли оно на ваш сайт
Вы уже можете опробовать изменение, начиная с Chrome 81: посетите chrome: // flags / # уменьшенный-referrer-granularity
в Chrome и включите флаг. Когда этот флаг
Если включено, все веб-сайты без политики будут использовать новый стандарт strict-origin-when-cross-origin
по умолчанию.
Теперь вы можете проверить, как ведет себя ваш веб-сайт и серверная часть.
Еще одна вещь, которую нужно сделать для обнаружения воздействия, — это проверить, использует ли кодовая база вашего веб-сайта реферер.
через заголовок Referer
входящих запросов на сервере или из document.referrer
в
JavaScript.
Некоторые функции на вашем сайте могут работать некорректно или работать иначе, если вы используете реферер запросы от другого источника к вашему сайту (точнее путь и / или строка запроса) И этот источник использует политику реферера браузера по умолчанию (т.е. для него не задана политика).
Если это повлияет на ваш сайт, рассмотрите альтернативы
Если вы используете реферер для доступа к полному пути или строке запроса для запросов к вашему сайту, вы есть несколько вариантов:
- Используйте альтернативные методы и заголовки, такие как
Origin
иSec-fetch-Site
для вашего CSRF защита, ведение журнала и другие варианты использования. Ознакомьтесь с политикой рефералов и рефереров: лучшее практики. - Вы можете согласовать с партнерами конкретную политику, если это необходимо и прозрачно для ваших пользователей.Контроль доступа — когда реферер используется веб-сайтами для предоставления определенного доступа к своим ресурсам.
к другому происхождению — это может быть такой случай, хотя с изменением Chrome происхождение по-прежнему будет
используется в заголовке
Referer
(и в документеdocument.referrer
).
Обратите внимание, что большинство браузеров движутся в том же направлении, когда дело доходит до реферера (см. значения по умолчанию и их развитие в Referer и Referrer-Policy: лучшее практики.
Реализуйте явную политику повышения конфиденциальности на своем сайте
What Referer
должен быть отправлен в запросах , отправленных вашим веб-сайтом, т. е.е. какая политика должна
вы установили для своего сайта?
Даже с учетом изменений в Chrome, неплохо было бы установить явную политику повышения конфиденциальности например, strict-origin-when-cross-origin
или более строгий прямо сейчас.
Это защищает ваших пользователей и заставляет ваш сайт вести себя более предсказуемо в браузерах. В основном это дает вам контроль — вместо того, чтобы ваш сайт зависел от настроек браузера по умолчанию.
Check Referer and Referrer-Policy: лучшие практики для подробности о настройке политики.
О Chrome Enterprise
Корпоративная политика Chrome ForceLegacyDefaultReferrerPolicy
доступен ИТ-администраторам, которые хотели бы принудительно применить предыдущую политику реферера по умолчанию no-referrer-when-downgrade
в корпоративных средах. Это дает предприятиям дополнительное время для
тестировать и обновлять свои приложения.
Эта политика будет удалена в Chrome 88.
Отправить отзыв
У вас есть отзыв или о чем сообщить? Поделитесь своим мнением о намерении Chrome корабль или твитнуть вопросы на @maudnals.
Большое спасибо за вклад и отзывы всем рецензентам, особенно Каустубха Говинд, Дэвид Ван Клив, Майк Уэст, Сэм Даттон, Роуэн Меревуд, Джекск и Кейси Баски.
ресурсов
Была ли эта страница полезной?
Есть
Что было самым лучшим на этой странице?
Это помогло мне выполнить мои цели
Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.Там была информация, которая мне была нужна
Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.Имеет точную информацию
Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.Легко читалось
Спасибо за ваш отзыв!Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.Что-то еще
Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.№
Что было самым плохим на этой странице?
Это не помогло мне выполнить мои цели
Спасибо за ваш отзыв!Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.Отсутствовала необходимая мне информация
Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.Он имел неточную информацию
Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.Трудно было прочитать
Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.Что-то еще
Спасибо за ваш отзыв! Если у вас есть конкретные идеи, как улучшить эту страницу, пожалуйста, создать проблему.Установка заголовка «Referer» с помощью JavaScript
Или: «Извините, вы снова сказали, что вы откуда?»
На предыдущем веб-семинаре по созданию полезных нагрузок межсайтового скриптинга (XSS), использующих оружие, я упоминал, что полезные нагрузки XSS (написанные на JavaScript) не могут изменить заголовок HTTP Referer . Вредоносные запросы, сделанные через полезную нагрузку XSS, часто имеют неожиданный заголовок Referer , который обычно не имеет смысла в нормальном рабочем процессе приложения.
К счастью, приложение, использованное в этой конкретной демонстрации, не проверяло заголовок Referer . Наша вредоносная полезная нагрузка работала, даже несмотря на то, что Referer был совершенно неверным.
Оказывается, я солгал вам, дорогие читатели — конечно, не намеренно.
Рисунок 1 — Я был неправ!Оказывается, вы действительно можете установить заголовок Referer с помощью JavaScript с помощью простого трюка, о котором я не знал в то время.
Но давайте сделаем резервную копию на секунду. Что это за заголовок Referer и почему я все время пишу его с ошибками?
Заголовок Referer устанавливается вашим браузером и отправляется на сервер, когда вы запрашиваете страницу. Значением этого заголовка является URL-адрес предыдущей страницы, которая ссылалась на недавно запрошенную страницу.По сути, это то место, откуда вы пришли.
И Referer написано с ошибками, потому что это неправильно написано в самом RFC еще в 1996 году — это совершенно не моя вина. Посмотрим, как это выглядит на практике.
Рисунок 2 — О том, как щелкнуть ссылку архиваКогда пользователь щелкает, чтобы перейти в раздел «Архивы» за декабрь 2019 года, фактический запрос, отправленный его браузером, устанавливает Referer в то место, откуда он пришел. В этом случае для Referer установлено значение http: // 192.168.78.157.
Рисунок 3 — Referer установлен на домашнюю страницуТеперь, когда мы находимся на странице архива, если мы перейдем по ссылке на этой странице, наш Referer будет установлен на страницу архива.
Рисунок 4 — О том, чтобы щелкнуть по недавнему сообщениюИ как только мы нажали на Кто больше всего его носил? Post, мы видим, что в запросе страница архива установлена как Referer .
Рис. 5. Referer, настроенный на архивную страницуИтак, почему мы, как злоумышленники, заинтересованы в контроле значения Referer ? Давайте посмотрим на пример из вооруженного вебинара XSS.
У нас есть уязвимое веб-приложение, в которое мы смогли внедрить вредоносный JavaScript через XSS-уязвимость, и мы можем делать запросы к приложению, используя сеанс нашей цели. Наша цель — администратор сайта в демонстрации, и мы будем использовать их уровень доступа, чтобы добавить нового администратора на сайт.
Перед тем, как запустить эксплойт, давайте посмотрим, как выглядит обычный запрос на добавление нового администратора. Ниже представлена форма, которую администратор заполняет для добавления нового пользователя.
Рисунок 6 — Форма нового пользователя находится на странице user-new.phpКогда эта форма заполняется и отправляется с информацией о новом пользователе, в сделанном запросе для Referer установлено значение http://192. 168.78.157 /wp-admin/user-new.php , где находится форма.
Рисунок 7 — POST для создания нового администратораМы можем сделать тот же запрос из нашего вредоносного JavaScript, чтобы добавить нового администратора; тем не менее, Referer будет установлен браузером цели как страница, на которую мы смогли внедрить наш вредоносный JavaScript.Функцию JavaScript, которую мы собираемся использовать в наших полезных данных для добавления нового администратора, можно увидеть на рисунке ниже:
Рисунок 8 — Пример вредоносной полезной нагрузки для добавления нового администратораКогда этот JavaScript запускается в браузере нашей цели, делается запрос на добавление нового пользователя-администратора с паролем, который нам (злоумышленнику) известен. В этом примере наш вредоносный JavaScript загружается со страницы предварительного просмотра сообщения в блоге, где конкретная уязвимость XSS, которую мы используем, размещает нашу полезную нагрузку. Это приводит к следующему запросу, в котором Referer настроен на страницу предварительного просмотра сообщения, а не на страницу нового пользователя, как это было бы при реальном запросе.
Рисунок 9. Подозрительное значение Referer, исходящее с неправильной страницыЭто неправильное значение Referer очень подозрительно, поскольку нет причин, по которым новое действие добавления пользователя должно исходить со страницы предварительного просмотра сообщения в блоге.
Рис. 10. Различные значения RefererК счастью, в нашем демонстрационном приложении WordPress не проверяет значения Referer .Но недавнее обсуждение с другом на эту самую тему вращалось вокруг приложения, которое использовало проверки по значению Referer в качестве меры безопасности. И приведенный ниже пример кода помог ему обойти этот контроль безопасности.
Итак, как мы можем получить контроль над заголовком Referer в JavaScript? Мы могли бы попытаться установить заголовок в нашем JavaScript, добавив следующий код:
Рисунок 11 — Попытка установить заголовок RefererНо браузер не позволяет нам сделать это:
Рисунок 12 — Браузер не позволяет установить RefererМы можем попытаться напрямую установить окно . document.referrer , но это тоже не работает.
Рисунок 13 — Большое спасибо, Modern Day BrowserК счастью, это невероятно простой трюк:
Рисунок 14 — Изменение записей историиРезультат изменения записи истории перед отправкой запроса приводит к измененному значению Referer :
Рис. 15. Referer установлен на ложное значениеОднако у этого подхода есть обратная сторона. Цель может заметить побочный эффект этого метода: URL-адрес страницы, на которой размещен наш вредоносный JavaScript, фактически изменился на желаемое значение Referer .Браузер фактически не загружает эту страницу. Фактически, приведенного ниже примера на самом деле не существует, но URL-адрес изменен для текущей страницы.
Рисунок 16. Изменение видимого URL-адресаВнимательный пользователь может заметить необычное поведение страницы. К счастью для нас, JavaScript чертовски быстр. Мы можем легко использовать запись в истории, чтобы изменить URL-адрес, сделать наш злонамеренный запрос, а затем снова изменить URL-адрес, прежде чем пользователь это заметит.
Прежде чем мы изменим URL-адрес пользователя, давайте возьмем копию текущего местоположения и сохраним ее.Таким образом, мы сможем восстановить URL-адрес, когда закончим с нашими махинациями. Давайте распечатаем некоторые значения в консоли, чтобы увидеть, что нам нужно сохранить, чтобы исправить URL-адрес, когда мы закончим.
Рисунок 17 — Печать соответствующих значений URL-адресовГлядя на значения, распечатанные на консоли, видно, что мы хотим, чтобы значения pathname и search были сохранены, если мы собираемся правильно восстановить URL-адрес при нашей атаке завершено. В качестве альтернативы вы также можете повторно выразить свойство href .
Рисунок 18 — Нам нужно сохранить путь и найти значенияПриведенный ниже код захватывает текущий URL, изменяет его на то, что нам нужно для желаемого значения Referer , а затем снова меняет его после добавления нашего новый администратор. Пользователь никогда не заметит изменение URL.
Рисунок 19 — Referer Value Switch-a-RooПлоды наших усилий дали нам Referer , который мы желаем:
Рисунок 20 — Значение псевдореферраИ URL-адрес мгновенно переключается обратно, прежде чем пользователь заметит:
Рисунок 21 — URL-адрес восстановленИтак, это простой метод управления значением Referer из JavaScript.Часто это не будет полезно. Немногие приложения будут проверять значение Referer как часть контроля безопасности, но они есть. Еще менее распространенный способ применить этот трюк — это приложение, которое отражает значение Referer (например, ссылка «вернуться»), потенциально открывая дверь для уязвимости XSS.
Их часто легко продемонстрировать с помощью Burp Repeater, вручную установив значение Referer с полезной нагрузкой JavaScript.Однако практическое использование маловероятно, поскольку все современные браузеры будут кодировать URL-адрес значение Referer перед его отправкой, нарушая полезные нагрузки XSS, SQLi и т. Д. Если вы найдете приложение, которое отражает заголовок Referer , который также, по какой-то необъяснимой причине, URL-адрес декодирует значение Referer , у вас будет уязвимость отраженного XSS, которую можно использовать.
Если вы все еще со мной, спасибо за то, что позволили мне исправить ошибки в некоторых из моих предыдущих сообщений в блоге, касающиеся возможности управления значением Referer .Если вы хотите узнать больше о вредоносных полезных нагрузках, использованных в демонстрации этого поста, см. Мой предыдущий пост в блоге и веб-семинар о вооружении полезными нагрузками XSS:
Блог: https://www.trustedsec.com/blog/tricks-for-weaponizing-xss/
Вебинар: https://www.trustedsec.com/events/webinar-popping-shells-instead-of-alert-boxes-weaponizing-xss-for-fun-and-profit/
Примеры кодана GitHub: https://github.com/hoodoer/WP-XSS-Admin-Funcs
Пример кода: https: // gist.