stringtranslate.com

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

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

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

Цели

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

Принудительное использование HTTPS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Опубликовать/Перенаправить/Получить

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

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

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

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

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

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

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

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

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

Выполнение

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

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

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

Перейдите по <a href="https://www.example.com/"> этой ссылке </a> .​ ​​​​

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

Коды статуса HTTP 3xx

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

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

Коды статуса 304 (не изменено) и 305 (использование прокси) не являются перенаправлениями.

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

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

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

HTTP / 1.1  301  Перемещено навсегда Расположение :  https://www.example.org/ Тип содержимого :  text/html Длина содержимого :  174< html > < head > < title > Перемещено </ title > </ head > < body >=Перемещено=< p > Эта страница перемещена на < a  href = "https://www.example.org/" > https://www.example.org/ </ a > . </ p > </ body > </ html >

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

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

header ( 'HTTP/1.1 301 перемещен навсегда' ); header ( 'Расположение: https://www.example.com/' ); выход ();

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

Apache HTTP-сервер mod_rewrite

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

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

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

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

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

переписать nginx

Nginx имеет интегрированный модуль перезаписи http, [10] который может использоваться для выполнения расширенной обработки URL и даже генерации веб-страниц (с returnдирективой). Показательным примером такого расширенного использования модуля перезаписи является mdoc.su Архивировано 3 апреля 2022 года на Wayback Machine , который реализует детерминированную службу сокращения URL полностью с помощью одного только языка конфигурации nginx. [11] [12]

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

 location /DragonFly { rewrite ^/DragonFly(BSD)?([,/].*)? $ /d $2 last ; } location /d { set $db "https://leaf.dragonflybsd.org/cgi/web-man?command=" ; set $ds "§ion=" ; rewrite ^/./([^/]+)\.([1-9]) $ $db$1$ds$2 redirect ; }

Метатег обновления и заголовок обновления HTTP

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

Вот пример простого HTML-документа, использующего эту технику:

< html > < head >  < meta  http-equiv = "Refresh"  content = "0; url=https://www.example.com/"  /> </ head > < body >  < p > Перейдите по < a  href = "https://www.example.com/" > этой ссылке </ a > . </ p > </ body > </ html >

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

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

HTTP / 1.1  200  OK Обновить :  0; url=https://www.example.com/ Тип содержимого :  text/html Длина содержимого :  78Перейдите по <a href="https://www.example.com/"> этой ссылке </a> .​ ​​​​

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

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

# !/usr/bin/perl print "Обновить: 0; url=https://www.example.com/\r\n" ; print "Тип контента: text/html\r\n" ; print "\r\n" ; print "Пожалуйста, перейдите по <a href=\"https://www.example.com/\">этой ссылке</a>!"

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

W3C не рекомендует использовать meta refresh, поскольку он не передает никакой информации об исходном или новом ресурсе браузеру (или поисковой системе ). W3C 's Web Content Accessibility Guidelines (7.4) [17] не рекомендует создавать автоматически обновляющиеся страницы, поскольку большинство веб-браузеров не позволяют пользователю отключать или контролировать частоту обновления. Некоторые статьи, которые они написали по этому вопросу, включают W3C Web Content Accessibility Guidelines (1.0): Обеспечьте пользователю контроль за изменениями контента, чувствительными к времени, Используйте стандартные перенаправления: не сломайте кнопку «Назад»! [18] и Основные методы для Web Content Accessibility Guidelines 1.0, раздел 7. [19]

JavaScript-перенаправления

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

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

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

окно . местоположение . замена ( 'https://www.example.com/' )

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

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

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

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

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

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

< frameset  rows = " 100% " > <  frame src  = " https://www.example.com/ " > <  noframes > <  body > Пожалуйста , перейдите по <a href="https://www.example.com/" > ссылке </a> . </body> < / noframes > < / frameset >

Цепочки перенаправления

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

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

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

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

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

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

Услуги

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

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

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

История

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

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

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

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

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

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

Проблемы безопасности

URL redirection can be abused by attackers to perform phishing attacks. If a redirect target is not sufficiently validated by a web application, an attacker can make a web application redirect to an arbitrary website. This vulnerability is known as an open-redirect vulnerability.[26][27] In certain cases when an open redirect occurs as part of an authentication flow, the vulnerability is known as a covert redirect.[28][29] When a covert redirect occurs, the attacker website can steal authentication information from the victim website.[26] Open redirect vulnerabilities are fairly common on the web. In June 2022, TechRadar found over 25 active examples of open redirect vulnerabilities on the web, including sites like Google and Instagram.[30] Open redirects have their own CWE identifier, CWE-601.[31]

URL redirection also provides a mechanism to perform cross-site leak attacks. By timing how long a website took to return a particular page or by differentiating one destination page from another, an attacker can gain significant information about another website's state. In 2021, Knittel et al. discovered a vulnerability in the Chrome's Performance API implementation which allowed them to reliably detect cross-origin redirects.[32]

See also

References

  1. ^ a b "Google revives redirect snoopery". Blog.anta.net. 29 January 2009. ISSN 1797-1993. Archived from the original on 17 August 2011.
  2. ^ "Redirects & SEO - The Total Guide". Audisto. Retrieved 29 November 2015.
  3. ^ "SEO advice: discussing 302 redirects". Matt Cutts, former Head of Google Webspam Team. 4 January 2006.
  4. ^ "Sneaky Redirects". Google Inc. 3 December 2015.
  5. ^ "Unvalidated Redirects and Forwards Cheat Sheet". Open Web Application Security Project (OWASP). 21 August 2014.
  6. ^ "Redirects & SEO - The Complete Guide". Audisto. Retrieved 29 November 2015.
  7. ^ "PHP Redirects: 302 to 301 Rock Solid Robust Solution". WebSiteFactors.co.uk. Archived from the original on 12 October 2012.
  8. ^ Roy T. Fielding; Julian F. Reschke, eds. (2014). "Location". Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. IETF. p. 68. sec. 7.1.2. doi:10.17487/RFC7231. RFC 7231.
  9. ^ Berners-Lee, Tim; Fielding, Roy T.; Masinter, Larry (2005). "Reference Resolution". Uniform Resource Identifier (URI): Generic Syntax. IETF. p. 28. sec. 5. doi:10.17487/RFC3986. RFC 3986.
  10. ^ "Module ngx_http_rewrite_module - rewrite". nginx.org. Retrieved 24 December 2014.
  11. ^ Murenin, Constantine A. (18 February 2013). "A dynamic web-site written wholly in nginx.conf? Introducing mdoc.su!". [email protected] (Mailing list). Retrieved 24 December 2014.
  12. ^ Murenin, Constantine A. (23 February 2013). "mdoc.su – Short manual page URLs for FreeBSD, OpenBSD, NetBSD and DragonFly BSD". Retrieved 25 December 2014.
  13. ^ Murenin, Constantine A. (23 February 2013). "mdoc.su.nginx.conf". Retrieved 25 December 2014.
  14. ^ "HTML meta tag". www.w3schools.com.
  15. ^ "An Exploration of Dynamic Documents". 2 August 2002. Archived from the original on 2 August 2002.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  16. ^ "Google and Yahoo accept undelayed meta refreshs as 301 redirects". Sebastian's Pamphlets. 3 September 2007.
  17. ^ "Web Content Accessibility Guidelines 1.0". www.w3.org.
  18. ^ Team, the QA. "Use standard redirects". www.w3.org.
  19. ^ "Core Techniques for Web Content Accessibility Guidelines 1.0". www.w3.org.
  20. ^ "Cross-browser client side URL redirect generator". Insider Zone. Archived from the original on 26 July 2020. Retrieved 27 August 2015.
  21. ^ Aaron Emigh (19 January 2005). "Anti-Phishing Technology" Archived 27 September 2007 at the Wayback Machine (PDF). Radix Labs.
  22. ^ "HTML 5.2: 11. Obsolete features". www.w3.org.
  23. ^ Schwartz, Barry (18 December 2007). "Double Redirects May Take Google More Time To Pick Up On". Search Engine Roundtable. Retrieved 28 January 2024.
  24. ^ Roy T. Fielding; Julian F. Reschke, eds. (2014). "Redirection 3xx". Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. IETF. p. 54. sec. 6.4. doi:10.17487/RFC7231. RFC 7231.
  25. ^ "Net gains for tiny Pacific nation". BBC News. 14 September 2007. Archived from the original on 12 May 2014. Retrieved 27 May 2010.
  26. ^ a b Innocenti, Tommaso; Golinelli, Matteo; Onarlioglu, Kaan; Mirheidari, Ali; Crispo, Bruno; Kirda, Engin (4 December 2023). "OAuth 2.0 Redirect URI Validation Falls Short, Literally". Annual Computer Security Applications Conference. ACSAC '23. New York, NY, USA: Association for Computing Machinery. pp. 256–267. doi:10.1145/3627106.3627140. hdl:11572/399070. ISBN 979-8-4007-0886-2.
  27. ^ "Open Redirect". OWASP. 16 March 2014. Retrieved 21 December 2014.
  28. ^ "Covert Redirect". Tetraph. 1 May 2014. Retrieved 21 December 2014.
  29. ^ "Serious security flaw in OAuth, OpenID discovered". CNET. 2 May 2014. Retrieved 21 December 2014.
  30. ^ Mike Williams (5 June 2022). "What is an Open Redirect vulnerability, why is it dangerous and how can you stay safe?". TechRadar. Retrieved 8 April 2024.
  31. ^ "CWE - CWE-601: URL Redirection to Untrusted Site ('Open Redirect') (4.14)". cwe.mitre.org. Retrieved 8 April 2024.
  32. ^ Knittel, Lukas; Mainka, Christian; Niemietz, Marcus; Noß, Dominik Trevor; Schwenk, Jörg (13 November 2021). "XSinator.com: From a Formal Model to the Automatic Evaluation of Cross-Site Leaks in Web Browsers". Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security. CCS '21. New York, NY, USA: Association for Computing Machinery. pp. 1771–1788. doi:10.1145/3460120.3484739. ISBN 978-1-4503-8454-4.

External links