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 ; }

Метатег Refresh и заголовок HTTP Refresh

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 может быть использовано злоумышленниками для выполнения фишинговых атак. Если цель перенаправления недостаточно проверена веб-приложением, злоумышленник может заставить веб-приложение перенаправить на произвольный веб-сайт. Эта уязвимость известна как уязвимость открытого перенаправления. [26] [27] В некоторых случаях, когда открытое перенаправление происходит как часть потока аутентификации , уязвимость известна как скрытое перенаправление. [28] [29] Когда происходит скрытое перенаправление, веб-сайт злоумышленника может украсть информацию об аутентификации с веб-сайта жертвы. [26] Уязвимости открытого перенаправления довольно распространены в Интернете. В июне 2022 года TechRadar обнаружил более 25 активных примеров уязвимостей открытого перенаправления в Интернете, включая такие сайты, как Google и Instagram . [30] Открытые перенаправления имеют свой собственный идентификатор CWE, CWE-601. [31]

Перенаправление URL также предоставляет механизм для выполнения атак с кросс-сайтовой утечкой . Определив, сколько времени потребовалось веб-сайту для возврата определенной страницы, или отличив одну целевую страницу от другой, злоумышленник может получить значительную информацию о состоянии другого веб-сайта. В 2021 году Книттель и др. обнаружили уязвимость в реализации API производительности Chrome, которая позволила им надежно обнаруживать кросс-доменные перенаправления. [32]

Смотрите также

Ссылки

  1. ^ ab "Google возрождает слежку за перенаправлениями". Blog.anta.net . 29 января 2009 г. ISSN  1797-1993. Архивировано из оригинала 17 августа 2011 г.
  2. ^ «Перенаправления и SEO — полное руководство» . Аудисто . Проверено 29 ноября 2015 г.
  3. ^ «Советы по SEO: обсуждение перенаправлений 302». Мэтт Каттс, бывший руководитель команды Google Webspam. 4 января 2006 г.
  4. ^ «Скрытые перенаправления». Google Inc. 3 декабря 2015 г.
  5. ^ "Шпаргалка по непроверенным перенаправлениям и пересылкам". Open Web Application Security Project (OWASP). 21 августа 2014 г.
  6. ^ "Перенаправления и SEO - Полное руководство". Audisto . Получено 29 ноября 2015 г.
  7. ^ "PHP Redirects: 302 to 301 Rock Solid Robust Solution". WebSiteFactors.co.uk. Архивировано из оригинала 12 октября 2012 г.
  8. ^ Рой Т. Филдинг; Джулиан Ф. Решке, ред. (2014). «Расположение». Протокол передачи гипертекста (HTTP/1.1): семантика и содержимое. IETF . стр. 68. раздел 7.1.2. doi : 10.17487/RFC7231 . RFC 7231.
  9. ^ Бернерс-Ли, Тим ; Филдинг, Рой Т .; Масинтер, Ларри (2005). «Reference Resolution». Универсальный идентификатор ресурса (URI): универсальный синтаксис. IETF . стр. 28. раздел 5. doi : 10.17487/RFC3986 . RFC 3986.
  10. ^ "Модуль ngx_http_rewrite_module - rewrite". nginx.org . Получено 24 декабря 2014 г. .
  11. ^ Муренин, Константин А. (18 февраля 2013 г.). "Динамический веб-сайт, написанный полностью на nginx.conf? Представляем mdoc.su!". [email protected] (список рассылки) . Получено 24 декабря 2014 г.
  12. ^ Муренин, Константин А. (23 февраля 2013 г.). "mdoc.su – URL-адреса страниц краткого руководства для FreeBSD, OpenBSD, NetBSD и DragonFly BSD" . Получено 25 декабря 2014 г. .
  13. ^ Муренин, Константин А. (23 февраля 2013 г.). "mdoc.su.nginx.conf" . Получено 25 декабря 2014 г. .
  14. ^ "HTML метатег". www.w3schools.com .
  15. ^ "Исследование динамических документов". 2 августа 2002 г. Архивировано из оригинала 2 августа 2002 г.{{cite web}}: CS1 maint: бот: исходный статус URL неизвестен ( ссылка )
  16. ^ "Google и Yahoo принимают незадержанные метаобновления как 301-редиректы". Sebastian's Pamphlets. 3 сентября 2007 г.
  17. ^ «Правила доступности веб-контента 1.0». www.w3.org .
  18. ^ Команда, QA. «Используйте стандартные перенаправления». www.w3.org .
  19. ^ «Основные методы для рекомендаций по обеспечению доступности веб-контента 1.0». www.w3.org .
  20. ^ "Cross-browser client side URL redirect generator". Insider Zone. Архивировано из оригинала 26 июля 2020 г. Получено 27 августа 2015 г.
  21. ↑ Аарон Эмиг (19 января 2005 г.). «Технология антифишинга» Архивировано 27 сентября 2007 г. на Wayback Machine (PDF). Radix Labs.
  22. ^ "HTML 5.2: 11. Устаревшие функции". www.w3.org .
  23. ^ Шварц, Барри (18 декабря 2007 г.). «Двойные перенаправления могут потребовать от Google больше времени для обнаружения». Круглый стол поисковых систем . Получено 28 января 2024 г.
  24. ^ Рой Т. Филдинг ; Джулиан Ф. Решке, ред. (2014). «Перенаправление 3xx». Протокол передачи гипертекста (HTTP/1.1): семантика и содержимое. IETF . стр. 54. раздел 6.4. doi : 10.17487/RFC7231 . RFC 7231.
  25. ^ "Чистый прирост для крошечной тихоокеанской нации". BBC News . 14 сентября 2007 г. Архивировано из оригинала 12 мая 2014 г. Получено 27 мая 2010 г.
  26. ^ ab Innocenti, Tommaso; Golinelli, Matteo; Onarlioglu, Kaan; Mirheidari, Ali; Crispo, Bruno; Kirda, Engin (4 декабря 2023 г.). "OAuth 2.0 Redirect URI Validation Falls Short, Literally". Ежегодная конференция по приложениям компьютерной безопасности . ACSAC '23. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. стр. 256–267. doi : 10.1145/3627106.3627140. hdl : 11572/399070 . ISBN 979-8-4007-0886-2.
  27. ^ "Open Redirect". OWASP. 16 марта 2014 г. Получено 21 декабря 2014 г.
  28. ^ "Скрытое перенаправление". Tetraph. 1 мая 2014 г. Получено 21 декабря 2014 г.
  29. ^ «Обнаружена серьезная уязвимость безопасности OAuth, OpenID». CNET. 2 мая 2014 г. Получено 21 декабря 2014 г.
  30. ^ Майк Уильямс (5 июня 2022 г.). «Что такое уязвимость Open Redirect, почему она опасна и как можно защитить себя?». TechRadar . Получено 8 апреля 2024 г.
  31. ^ "CWE - CWE-601: Перенаправление URL на ненадежный сайт ('Открытое перенаправление') (4.14)". cwe.mitre.org . Получено 8 апреля 2024 г. .
  32. ^ Книттель, Лукас; Майнка, Кристиан; Ниемитц, Маркус; Носс, Доминик Тревор; Швенк, Йорг (13 ноября 2021 г.). «XSinator.com: от формальной модели к автоматической оценке межсайтовых утечек в веб-браузерах». Труды конференции ACM SIGSAC 2021 года по компьютерной и коммуникационной безопасности . CCS '21. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. стр. 1771–1788. doi : 10.1145/3460120.3484739. ISBN 978-1-4503-8454-4.

Внешние ссылки