Перенаправление URL

Перенаправление URL-адресов в Википедии см. в разделе Википедия:Перенаправление.

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

Перенаправление URL - адресов осуществляется по разным причинам:

для сокращения URL-адресов;

чтобы предотвратить неработающие ссылки при перемещении веб-страниц;

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

для навигации по веб-сайту и выхода из него;

для защиты конфиденциальности; и

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

Цели

Существует несколько причин для использования перенаправления URL-адресов:

Форсирование HTTPS

Веб-сайт потенциально может быть доступен как по защищенной схеме URI HTTPS, так и по обычному HTTP (небезопасный URI, начинающийся с "http://").

Если пользователь вводит URI или нажимает на ссылку, которая ссылается на небезопасный вариант, браузер автоматически перенаправляет на безопасную версию в случае, если веб-сайт содержится в списке предварительной загрузки HSTS, поставляемом вместе с приложением, или если пользователь уже посещал источник в прошлом.

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

Похожие доменные имена

Пользователь может неправильно ввести URL-адрес. Организации часто регистрируют эти домены с "ошибками" и перенаправляют их в "правильное" место. Этот метод часто используется для "резервирования" других доменов верхнего уровня (TLD) с тем же именем или для облегчения размещения сайта ".edu" или ".net" для пользователей, вводящих ".com".

Перемещение страниц в новый домен

Веб-страницы могут быть перенаправлены на новый домен по трем причинам:

• сайт может захотеть или нуждаться в смене своего доменного имени;
• автор может перенести свои отдельные страницы в новый домен;
• два веб-сайта могут объединиться.

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

Регистрация исходящих ссылок

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

Короткие псевдонимы для длинных URL-адресов

Основная статья: Сокращение URL-адресов

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

Значимые, постоянные псевдонимы для длинных или меняющихся URL-адресов

См. также: Permalink, PURL и Link rot

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

Post/Redirect/Get

Основная статья: Post/Redirect/Get

Post/Redirect/Get (PRG) - это шаблон проектирования веб-разработки , который предотвращает некоторые повторяющиеся отправки форм, если пользователь нажимает кнопку обновить после отправки формы, создавая более интуитивно понятный интерфейс для агентов пользователей (пользователей).

Таргетинг на устройства и геотаргетинг

Редиректы могут быть эффективно использованы для таргетинга, такого как геотаргетинг. Таргетинг на устройства становится все более важным с появлением мобильных клиентов. Существует два подхода к обслуживанию мобильных пользователей: сделать сайт адаптивным или перенаправить на мобильную версию сайта. Если предлагается мобильная версия сайта, пользователи с мобильными клиентами будут автоматически перенаправлены на соответствующий мобильный контент. Для таргетинга устройств используются перенаправления на стороне клиента или некешируемые перенаправления на стороне сервера. Геотаргетинг-это подход к предложению локализованного контента и автоматической переадресации пользователя на локализованную версию запрашиваемого URL-адреса. Это полезно для сайтов, целевой аудиторией которых является более одного места и/или языка. Обычно перенаправление на стороне сервера используется для геотаргетинга, но перенаправление на стороне клиента также может быть вариантом, в зависимости от требований.

Манипулирование поисковыми системами

Редиректы используются для манипулирования поисковыми системами с неэтичными намерениями, например, для захвата URL-адресов. Цель вводящих в заблуждение редиректов состоит в том, чтобы привлечь поисковый трафик на целевые страницы, которые сами по себе не обладают достаточной ранжирующей способностью или которые только отдаленно или вообще не связаны с целью поиска. Этот подход требует ранга для ряда поисковых запросов с несколькими URL-адресами, которые будут использовать скрытое перенаправление для перенаправления пользователя на целевую страницу. Этот метод возродился с появлением мобильных устройств и таргетинга на устройства. Угон URL-адресов-это метод переадресации вне домена[3] это использовало характер обработки поисковой системой временных редиректов. Если встречается временное перенаправление, поисковые системы должны решить, присваивать ли они значение ранжирования URL-адресу, который инициализирует перенаправление, или целевому URL-адресу перенаправления. URL-адрес, инициирующий перенаправление, может быть сохранен для отображения в результатах поиска, так как перенаправление указывает на временный характер. При определенных обстоятельствах можно было использовать это поведение, применяя временные редиректы к хорошо ранжированным URL-адресам, что приводило к замене исходного URL-адреса в результатах поиска URL-адресом, инициализировавшим редирект, и, следовательно, "краже" рейтинга. Этот метод обычно сочетался с скрытыми перенаправлениями, чтобы перенаправить поток пользователей из результатов поиска на целевую страницу. Поисковые системы разработали эффективные технологии для выявления такого рода манипулятивных подходов. Крупные поисковые системы обычно применяют жесткие штрафы за ранжирование сайтов, которые попадаются на применении подобных методов.

Манипулирование посетителями

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

Удаление referrerинформации

При нажатии на ссылку браузер отправляет в HTTP-запросе поле referer, которое указывает источник ссылки. Это поле заполняется URL-адресом текущей веб-страницы и попадает в журналы сервера, обслуживающего внешнюю ссылку. Поскольку конфиденциальные страницы могут иметь конфиденциальные URL-адреса (например, http://company.com/plans-for-the-next-release-of-our-product), нежелательно, чтобы referrerURL-адрес покидал организацию. Страница перенаправления, которая выполняет скрытие реферера, может быть встроена во все внешние URL-адреса, преобразовавшись, напримерhttp://externalsite.com/page, в http://redirect.company.com/http://externalsite.com/page. Этот метод также устраняет другую потенциально конфиденциальную информацию из URL-адреса реферера, такую как идентификатор сеанса, и может снизить вероятность фишинга, указав конечному пользователю, что он прошел через открытый шлюз на другой сайт.

Реализация

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

Ручное перенаправление

Самый простой метод-попросить посетителя перейти по ссылке на новую страницу, обычно используя HTML-якорь типа:

Пожалуйста, следуйте <a  href="http://www.example.com/">>эта ссылка</a>>.

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

Коды состояния HTTP 3xx

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

HTTP/1.1 определяет несколько кодов состояния для перенаправления (RFC 7231):

300 множественный выбор (например, предложение разных языков)

301 перемещен навсегда (постоянно перенаправляет с одного URL-адреса на другой, передавая ссылку на перенаправленную страницу)

найдено 302 (первоначально "временное перенаправление" в HTTP/1.0 и широко используемое для CGI-скриптов; заменено 303 и 307 в HTTP/1.1, но сохранено для обратной совместимости)

303 см. другое (принудительно отправляет запрос GET на новый URL-адрес, даже если исходный запрос был POST)

305 использовать прокси-сервер (указывает, что запрошенный клиентом ресурс доступен только через прокси-сервер)

307 временное перенаправление (предоставляет новый URL-адрес браузеру для повторной отправки запроса GET или POST)

308 постоянный редирект (предоставляет новый URL-адрес браузеру для повторной отправки запроса GET или POST)

Коды состояния 304 not modified и 305 use proxy не являются перенаправлениями.

Перенаправление коды состояния и характеристики

Код состояния HTTP	HTTP-версия	Временный / Постоянный	Кэшируемый	Метод запроса Последующий запрос
301	HTTP/1.0	Постоянный	ДА	GET / POST может измениться
302	HTTP/1.0	Временная	не по умолчанию	GET / POST может измениться
303	HTTP/1.1	Временная	никогда	всегда ПОЛУЧАЮ
307	HTTP/1.1	Временная	не по умолчанию	может и не измениться
308	HTTP/1.1	Постоянный	по умолчанию	может и не измениться

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

Пример HTTP-ответа для 301-го перенаправления

HTTP - ответ с 301-м перенаправлением "перемещен навсегда" выглядит следующим образом:

>>title< >> head
<>> html
<174 :
Content-Length text/html :

Content-Type http://www.example.org/:Location
Перемещено навсегда 301
1.1/HTTP Перемещено</title>>
</head>>
<body>>
=Переехал=

>Эта страница переместилась в <a href="http://www.example.org/">>http://www.example.org/</a>>.

>

</body>>
</html>>

Использование серверных сценариев для перенаправления

Веб-авторы, создающие HTML-контент, обычно не могут создавать редиректы с использованием HTTP-заголовков, поскольку они автоматически генерируются программой веб-сервера при обслуживании HTML-файла. То же самое обычно верно даже для программистов, пишущих CGI-скрипты, хотя некоторые серверы позволяют скриптам добавлять пользовательские заголовки (например, включив "non-parsed-headers"). Многие веб-серверы генерируют код состояния 3xx, если скрипт выводит строку заголовка "Location:". Например, в PHP можно использовать функцию "заголовок" :

заголовок("HTTP/1.1 301 перемещен навсегда");
заголовок("Местоположение: http://www.example.com/');
exit();

Для предотвращения кэширования может потребоваться больше заголовков. Программист должен убедиться, что заголовки выводятся перед телом. Это может нелегко вписаться в естественный поток управления через код. Чтобы помочь в этом, некоторые фреймворки для генерации контента на стороне сервера могут буферизировать данные тела. В языке сценариев ASP это также может быть достигнуто с помощью response.buffer=trueresponse.redirect "http://www.example.com/"HTTP/1.1, который допускает либо относительную ссылку URI, либо абсолютную ссылку URI. Если ссылка URI относительна, клиент вычисляет требуемую абсолютную ссылку URI в соответствии с правилами, определенными в RFC 3986.

Apache HTTP Server mod_rewrite

Расширение Apache HTTP Server mod_alias можно использовать для перенаправления определенных запросов. Типичные директивы конфигурации выглядят следующим образом:

Перенаправление постоянный /oldpage.html http://www.example.com/newpage.html 
Перенаправление  301/oldpage.html  http://www.example.com/newpage.html

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

RewriteCond  on
 RewriteEngine %{HTTP_HOST} ^([^.:]+\.)*oldsite\.example\.com\.?(:[0-9]*)?$ [НК]
RewriteRule ^(.*)$ http://newsite.example.net/$1 [R=301,L]

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

nginx переписать

Nginx имеет встроенный модуль http rewrite, который может использоваться для выполнения расширенной обработки URL-адресов и даже генерации веб-страниц (с returnпомощью директивы). Показательным примером такого расширенного использования модуля перезаписи является mdoc.su, который реализует детерминированную службу сокращения URL-адресов полностью с помощью только языка конфигурации nginx.

Например, если запрос /DragonFlyBSD/HAMMER.5 был приехать вместе, следует в первую очередь направленного внутрь, чтобы /d/HAMMER.5 с первого переписать директиву ниже (влияет только на внутреннее состояние, без любой HTTP-ответы, и выдается клиенту только пока), а затем со второй переписать директиву, в ответ HTTP с 302 найден код состояния может быть выдан клиенту на самом деле перенаправление на внешний CGI-скрипт на веб-мужчина:

^/DragonFly(BSD)?([,/].*)? переписать {
 /Стрекоза расположение$ /д$2 последних;
}
местоположение /д {
 набор $дБ "http://leaf.dragonflybsd.org/cgi/web-man?command=";
 набор $ДС "&разделе=";
 переписывать ^/./([^/]+)\.([1-9])$ $дБ,$1$ДС$2 перенаправлений;
}

Обновить мета - тег и заголовок обновления HTTP

Netscape представила функцию meta refresh, которая обновляет страницу через определенное время. Это может указать новый URL-адрес для замены одной страницы другой. Это поддерживается большинством веб-браузеров.[14][15] Тайм-аут в ноль секунд приводит к немедленному перенаправлению. Это рассматривается Google как 301 постоянный редирект, позволяющий перенести PageRank на целевую страницу.[16]

Это пример простого HTML - документа, который использует эту технику:

>п<
>тело<
 >голова <//>"0; url=НТТР://ВСП.пример.ком/" =материалам"обновить" =
НТТР-эквмета<
>голова<
 >в HTML<пожалуйста, <в href, в="http://www.example.com/">этой ссылке</а>.</п>
</тело>
</HTML с>

Этот метод может быть использован веб-авторами, поскольку мета-тег содержится внутри самого документа. Мета-тег должен быть помещен в раздел "head" HTML-файла. Число "0" в этом примере может быть заменено другим числом, чтобы добиться задержки на столько секунд. Якорь в разделе "тело" предназначен для пользователей, чьи браузеры не поддерживают эту функцию.

Тот же эффект может быть достигнут с помощью HTTPrefresh-заголовка:

78:Content-Length  text/html :
Content-Type 0; url=http:/ / 
www.example.com/:Refresh OK  200
1.1/ HTTP

Пожалуйста, следуйте <a href="http://www.example.com/">>эта ссылка</a>>.

Этот ответ легче генерировать CGI-программами, поскольку не нужно изменять код состояния по умолчанию.

Вот простая CGI-программа, которая влияет на это перенаправление:

# !/usr/Бен/Perl для
печати "обновить: 0; url=НТТР://ВСП.пример.ком/\г\п";
печать "содержимое-тип: текст/HTML\р\п";
печать "\г\п";
печать "пожалуйста, следуйте <a href="\"http://www.example.com/\"">этой ссылке</a>!"

Примечание: Обычно HTTP-сервер автоматически добавляет строку состояния и заголовок Content-Length.

W3C не рекомендует использовать meta refresh, поскольку он не передает никакой информации ни об исходном, ни о новом ресурсе браузеру (или поисковой системе). Рекомендации по доступности веб-контента W3C (7.4) препятствуют созданию автоматически обновляемых страниц, поскольку большинство веб-браузеров не позволяют пользователю отключать или контролировать частоту обновления. Некоторые статьи, которые они написали по этому вопросу, включают W3C Web Content Accessibility Guidelines (1.0):Обеспечьте контроль пользователя над изменениями контента, чувствительными ко времени, используйте стандартные перенаправления: не ломайте кнопку назад! и Основные методы обеспечения доступности веб-контента 1.0 раздел 7.

Перенаправление JavaScript

JavaScript может вызвать перенаправление, установив window.locationатрибут, например::

окно.местоположение='http://www.example.com/'

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

window.location.replace('http://www.example.com/')

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

Перенаправление кадров

Несколько иного эффекта можно добиться, создав встроенный фрейм:

>>"http://www.example.com/" =src"100%" =ширина"100%" =высота iframe<
Пожалуйста, следуйте <a  href="http://www.example.com/">>ссылка</a>>.
</iframe>

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

До HTML5[22] тот же эффект мог быть достигнут с HTML-фреймом, содержащим целевую страницу.:

>тело <>noframes<
 >"http://www.example.com/" =ГРЦкаркаса<
 >"100%"=
   строкифреймов<пожалуйста, <в href, в="http://www.example.com/">ссылка</а>.</тело>
 </noframes>
</frameset для>

Перенаправление цепи

Одно перенаправление может привести к другому. Например, URL-адрес "http://wikipedia.com" (с доменом "*.com") сначала перенаправляется на https://www.wikipedia.org/ (с доменным именем в .org), где вы можете перейти на сайт, зависящий от языка. Это неизбежно, если разные ссылки в цепочке обслуживаются разными серверами, хотя это должно быть сведено к минимуму, переписав URL-адрес как можно больше на сервере, прежде чем возвращать его в браузер в качестве перенаправления.

Википедия перенаправляет свои страницы на HTTPS по умолчанию с 2015 года.

Перенаправление петли

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

Стандарт HTTP/1.1 гласит:

1. Клиент ДОЛЖЕН обнаруживать циклические перенаправления (т. Е. "бесконечные" циклы перенаправления) и вмешиваться в них.

1. Примечание: В более ранней версии этой спецификации рекомендовалось не более пяти перенаправлений ([RFC 2068], раздел 10.3). Разработчики контента должны знать, что некоторые клиенты могут реализовать такое фиксированное ограничение.

Обратите внимание, что URL-адреса в последовательности могут не повторяться, например: http://www.example.com/1[постоянная мертвая ссылка] -> >http://www.example.com/2[постоянная мертвая ссылка] -> >http://www.example.com/3[постоянная мертвая связь] ...

Услуги

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

Услуги перенаправления URL-адресов

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

История

Первые службы перенаправления использовали домены верхнего уровня (TLD), такие как ".to" (Тонга), ". at" (Австрия) и ".is" (Исландия). Их цель состояла в том, чтобы сделать запоминающиеся URL-адреса. Первой основной службой перенаправления была V3.com на пике своего развития в 2000 году он насчитывал 4 миллиона пользователей. V3.com успех был обусловлен наличием широкого спектра коротких запоминающихся доменов, включая "r.im", "go.to", "i.am", "come.to" и "start.at. V3.com был приобретен FortuneCity.com, крупная бесплатная веб-хостинговая компания, в начале 1999 года.[25] Когда цена продажи доменов верхнего уровня начала падать с 70 долларов.00 в год до менее чем $10.00, использование услуг перенаправления сократилось. С запуском TinyURL в 2002 году родился новый вид сервиса перенаправления, а именно сокращение URL-адресов. Их цель состояла в том, чтобы сделать длинные URL-адреса короткими, чтобы иметь возможность размещать их на интернет-форумах. С 2006 года, с ограничением на 140 символов в чрезвычайно популярном сервисе Twitter, эти короткие URL-адреса широко используются.

Маскировка реферера

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

Вот упрощенный пример такого сервиса, написанного на PHP.

>>
заголовок < >>заголовок<>>html<
-->?>); $url .'Refresh: 0; url=https://'
(
header
]);'url'[
$_GET(htmlspecialchars
 =$url<?phpRedirecting...</title>
 <meta http-equiv="refresh" content="0;url=https://<?= $url; ?>">
</head>
<body>
Попытка перенаправления на <a  href="https://<?= $url; ?>>">>https://<?= $url; ?>></a>>.
</body>
</html>

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

Вопросы безопасности

Перенаправление URL-адресов может быть использовано злоумышленниками для фишинговых атак, таких как открытое перенаправление и скрытое перенаправление. "Открытое перенаправить приложение, которое принимает параметр и перенаправляет пользователя на значение параметра без какой-либо проверки". "скрытое перенаправление является приложением, которое принимает параметр и перенаправляет пользователя на значение параметра без достаточной проверки." Это была раскрыта в мае 2014 математической докторант Ван Цзин из Наньянского технологического университета, Сингапур.

См. также

• Расположение HTTP
• Канонический элемент связи
• Канонический метатег
• Маскировка домена
• Ссылка гниль
• Семантический URL
• Нормализация URL-адресов

Пруф

httpd.apache.org/docs/2.4/en/urlmapping.html

• www2007.org/workshops/paper_115.
• projects.webappsec.org/w/page/13246981/URL%20Redirector%20Abuse
• youtube.com/D7Egnbx7B3Y