перенаправление URL-адресов
Перенаправление URL-адресов , также называемое перенаправлением URL-адресов , представляет собой метод Всемирной паутины , позволяющий сделать веб-страницу доступной по нескольким URL- адресам. Когда веб-браузер пытается открыть URL-адрес, который был перенаправлен, открывается страница с другим URL-адресом. URL Аналогичным образом, перенаправление домена или перенаправление домена — это когда все страницы в домене перенаправляются в другой домен, например, когда wikipedia.com и wikipedia.net автоматически перенаправляются на wikipedia.org .
Перенаправление URL-адресов выполняется по разным причинам:
- для сокращения URL-адресов ;
- для предотвращения неработающих ссылок при перемещении веб-страниц;
- разрешить нескольким доменным именам, принадлежащим одному и тому же владельцу, ссылаться на один веб-сайт ;
- для управления переходом на веб-сайт и выходом из него;
- для защиты конфиденциальности (например, перенаправление ссылок YouTube и Twitter на Invidious и Nitter соответственно или превращение ссылок AMP в обычные ссылки); и
- во враждебных целях, таких как фишинговые атаки или распространение вредоносного ПО.
Цели
[ редактировать ]Есть несколько причин использовать перенаправление 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-адрес с более короткого. [ 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), нежелательно referrer URL-адрес для выхода из организации. Страница перенаправления, которая скрывает реферер, может быть встроена во все внешние URL-адреса, преобразуя, например, https://externalsite.com/page в https://redirect.company.com/https://externalsite.com/page. Этот метод также исключает другую потенциально конфиденциальную информацию из URL-адреса реферера, такую как идентификатор сеанса , и может снизить вероятность фишинга , указывая конечному пользователю, что он передал чистый шлюз на другой сайт.
Выполнение
[ редактировать ]Несколько различных типов ответа браузеру приведут к перенаправлению. Они различаются в зависимости от того, влияют ли они на заголовки HTTP или на содержимое HTML. Используемые методы обычно зависят от роли человека, реализующего их, и его доступа к различным частям системы. Например, веб-автор, не имеющий контроля над заголовками, может использовать метатег «Обновить» , тогда как администратор веб-сервера, перенаправляющий все страницы сайта, с большей вероятностью будет использовать конфигурацию сервера.
Ручное перенаправление
[ редактировать ]Самый простой метод — попросить посетителя перейти по ссылке на новую страницу, обычно используя привязку HTML, например:
Please follow <a href="https://www.example.com/">this link</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 не изменено и 305 использовать прокси не являются перенаправлениями.
| Код состояния 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 «перемещено навсегда» выглядит следующим образом:
HTTP/1.1 301 Moved Permanently
Location: https://www.example.org/
Content-Type: text/html
Content-Length: 174
<html>
<head>
<title>Moved</title>
</head>
<body>
=Moved=
<p>This page has moved to <a href="https://www.example.org/">https://www.example.org/</a>.</p>
</body>
</html>
Использование серверных сценариев для перенаправления
[ редактировать ]Веб-авторы, создающие HTML-контент, обычно не могут создавать перенаправления с использованием HTTP-заголовков, поскольку они автоматически генерируются программой веб-сервера при обслуживании HTML-файла. То же самое обычно справедливо даже для программистов, пишущих сценарии CGI, хотя некоторые серверы позволяют сценариям добавлять собственные заголовки (например, путем включения «неразбираемых заголовков»). Многие веб-серверы генерируют код состояния 3xx, если сценарий выводит строку заголовка «Location:». Например, в PHP можно использовать функцию «заголовок»:
header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/');
exit();
Для предотвращения кэширования могут потребоваться дополнительные заголовки. [ 7 ] Программист должен убедиться, что заголовки выводятся раньше тела. Это может нелегко сочетаться с естественным потоком управления через код. Чтобы помочь в этом, некоторые платформы для создания контента на стороне сервера могут буферизовать данные тела. На языке сценариев ASP это также можно сделать с помощью response.buffer=true и response.redirect "https://www.example.com/" HTTP/1.1 допускает либо относительную ссылку URI, либо абсолютную ссылку URI. [ 8 ] Если ссылка URI является относительной, клиент вычисляет необходимую абсолютную ссылку URI в соответствии с правилами, определенными в RFC 3986. [ 9 ]
HTTP-сервер Apache mod_rewrite
[ редактировать ]Расширение mod_alias Apache HTTP Server можно использовать для перенаправления определенных запросов. Типичные директивы конфигурации выглядят так:
Redirect permanent /oldpage.html https://www.example.com/newpage.html
Redirect 301 /oldpage.html https://www.example.com/newpage.html
Для более гибкого перезаписи и перенаправления URL-адресов можно использовать Apache mod_rewrite. Например, чтобы перенаправить запросы на каноническое доменное имя:
RewriteEngine on
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-скрипт веб- человека : [ 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 представил функцию метаобновления , которая обновляет страницу через определенное время. Это может указать новый URL-адрес для замены одной страницы другой. Это поддерживается большинством веб-браузеров. [ 14 ] [ 15 ] Тайм-аут в ноль секунд приводит к немедленному перенаправлению. Google рассматривает это как постоянное перенаправление 301, позволяя передавать PageRank на целевую страницу. [ 16 ]
Это пример простого HTML-документа, в котором используется этот метод:
<html>
<head>
<meta http-equiv="Refresh" content="0; url=https://www.example.com/" />
</head>
<body>
<p>Please follow <a href="https://www.example.com/">this link</a>.</p>
</body>
</html>
Этот метод могут использовать веб-авторы , поскольку метатег содержится внутри самого документа. Метатег должен быть размещен в разделе «head» HTML-файла. Число «0» в этом примере можно заменить другим числом, чтобы добиться задержки на такое же количество секунд. Якорь в разделе «body» предназначен для пользователей, браузеры которых не поддерживают эту функцию.
Того же эффекта можно добиться с помощью HTTP refresh заголовок:
HTTP/1.1 200 OK
Refresh: 0; url=https://www.example.com/
Content-Type: text/html
Content-Length: 78
Please follow <a href="https://www.example.com/">this link</a>.
Этот ответ легче сгенерировать с помощью программ CGI, поскольку не нужно менять код состояния по умолчанию.
Вот простая программа CGI, которая осуществляет это перенаправление:
# !/usr/bin/perl
print "Refresh: 0; url=https://www.example.com/\r\n";
print "Content-Type: text/html\r\n";
print "\r\n";
print "Please follow <a href=\"https://www.example.com/\">this link</a>!"
Примечание. Обычно HTTP-сервер автоматически добавляет строку состояния и заголовок Content-Length.
W3C ) никакой информации ни об исходном , не рекомендует использовать метаобновление, поскольку оно не передает браузеру (или поисковой системе ни о новом ресурсе . Рекомендации W3C по обеспечению доступности веб-контента (7.4) [ 17 ] не рекомендуется создавать страницы с автоматическим обновлением, поскольку большинство веб-браузеров не позволяют пользователю отключать или контролировать частоту обновления. Некоторые статьи, которые они написали по этой проблеме, включают Рекомендации W3C по обеспечению доступности веб-контента (1.0): Обеспечьте пользователю контроль над изменениями контента, зависящими от времени . Используйте стандартные перенаправления: не нажимайте кнопку «Назад»! [ 18 ] и Основные методы для Руководства по обеспечению доступности веб-контента 1.0, раздел 7. [ 19 ]
Перенаправления JavaScript
[ редактировать ]JavaScript может вызвать перенаправление, установив window.location атрибут, например:
window.location='https://www.example.com/'
сайта-перенаправителя Обычно JavaScript помещает URL-адрес в историю браузера. Это может вызвать циклы перенаправления, когда пользователи нажимают кнопку «Назад». С помощью следующей команды вы можете предотвратить такое поведение. [ 20 ]
window.location.replace('https://www.example.com/')
Однако HTTP-заголовки или метатег обновления могут быть предпочтительнее по соображениям безопасности, а также потому, что некоторые браузеры и многие веб-сканеры не выполняют JavaScript .
Перенаправление кадров
[ редактировать ]Немного другого эффекта можно добиться, создав встроенный фрейм :
<iframe height="100%" width="100%" src="https://www.example.com/">
Please follow <a href="https://www.example.com/">link</a>.
</iframe>
Одним из основных отличий от вышеуказанных методов перенаправления является то, что при перенаправлении фрейма браузер отображает URL-адрес документа фрейма, а не URL-адрес целевой страницы в строке URL-адреса. Эту технику маскировки можно использовать для того, чтобы читатель увидел более запоминающийся URL-адрес или чтобы обманным путем скрыть фишинговый сайт в рамках подделки веб-сайта . [ 21 ]
До появления HTML5 [ 22 ] тот же эффект можно добиться с помощью HTML-фрейма , содержащего целевую страницу:
<frameset rows="100%">
<frame src="https://www.example.com/">
<noframes>
<body>Please follow <a href="https://www.example.com/">link</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, который на пике своего развития в 2000 году имел 4 миллиона пользователей. Успех V3.com объяснялся наличием большого количества коротких запоминающихся доменов, включая «r.im», «go.to», «i». .am», «come.to» и «start.at». V3.com был приобретен FortuneCity.com, крупной компанией бесплатного веб-хостинга, в начале 1999 года. [ 25 ] Поскольку цена продажи доменов верхнего уровня начала падать с 50 долларов США в год до менее 10 долларов США в год , использование услуг перенаправления сократилось. С запуском TinyURL в 2002 году появился новый вид службы перенаправления, а именно сокращение URL-адресов . Их целью было сделать длинные URL-адреса короткими, чтобы можно было размещать их на интернет-форумах. С 2006 года, когда в чрезвычайно популярном сервисе Twitter было установлено ограничение в 140 символов , эти службы коротких URL-адресов стали активно использоваться.
Маскировка реферера
[ редактировать ]Службы перенаправления могут скрыть реферер , разместив промежуточную страницу между страницей, на которой находится ссылка, и ее местом назначения. Хотя они концептуально похожи на другие службы перенаправления URL-адресов, они служат другой цели и редко пытаются сократить или запутать целевой URL-адрес (поскольку их единственный предполагаемый побочный эффект — скрыть информацию о реферере и обеспечить четкий шлюз между другими веб-сайтами). ) Этот тип перенаправления часто используется для предотвращения получения потенциально вредоносными ссылками информации с помощью реферера, например идентификатора сеанса в строке запроса. Многие веб-сайты крупных сообществ используют перенаправление ссылок на внешние ссылки, чтобы уменьшить вероятность использования эксплойта, который может быть использован для кражи информации об учетной записи, а также дать понять, когда пользователь покидает службу, чтобы уменьшить вероятность эффективного фишинга .
Вот упрощенный пример такого сервиса, написанный на PHP .
<?php
$url = htmlspecialchars($_GET['url']);
header('Refresh: 0; url=https://' . $url);
?>
<!-- Fallback using meta refresh. -->
<html>
<head>
<title>Redirecting...</title>
<meta http-equiv="refresh" content="0;url=https://<?= $url; ?>">
</head>
<body>
Attempting to redirect to <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 ]
См. также
[ редактировать ]- Канонический элемент ссылки
- Очистить URL-адрес
- Маскирование домена
- HTTP-расположение
- Ссылка гнилая
- Нормализация URI
Ссылки
[ редактировать ]- ^ Перейти обратно: а б «Google возрождает отслеживание перенаправлений» . Блог.anta.net . 29 января 2009 г. ISSN 1797-1993 . Архивировано из оригинала 17 августа 2011 года.
- ^ «Редиректы и SEO — полное руководство» . Аудисто . Проверено 29 ноября 2015 г.
- ^ «Совет по SEO: обсуждаем 302 редиректы» . Мэтт Каттс, бывший руководитель группы Google по борьбе со спамом. 4 января 2006 г.
- ^ «Скрытые редиректы» . Google Inc., 3 декабря 2015 г.
- ^ «Шпаргалка по непроверенным перенаправлениям и переадресациям» . Открытый проект безопасности веб-приложений (OWASP). 21 августа 2014 г.
- ^ «Редиректы и SEO — Полное руководство» . Аудисто . Проверено 29 ноября 2015 г.
- ^ «Перенаправления PHP: с 302 по 301 Надежное и надежное решение» . WebSiteFactors.co.uk. Архивировано из оригинала 12 октября 2012 года.
- ^ Рой Т. Филдинг; Джулиан Ф. Решке, ред. (2014). "Расположение" . Протокол передачи гипертекста (HTTP/1.1): семантика и содержание . IETF . п. 68. сек. 7.1.2. дои : 10.17487/RFC7231 . РФК 7231 .
- ^ Бернерс-Ли, Тим ; Филдинг, Рой Т .; Масинтер, Ларри (2005). «Справочное разрешение» . Единый идентификатор ресурса (URI): общий синтаксис . IETF . п. 28. сек. 5. дои : 10.17487/RFC3986 . РФК 3986 .
- ^ «Модуль ngx_http_rewrite_module — переписать» . nginx.org . Проверено 24 декабря 2014 г.
- ^ Муренин, Константин А. (18 февраля 2013 г.). «Динамический веб-сайт, полностью написанный на nginx.conf? Представляем mdoc.su!» . [электронная почта защищена] (список рассылки) . Проверено 24 декабря 2014 г.
- ^ Муренин, Константин А. (23 февраля 2013 г.). «mdoc.su — URL-адреса кратких страниц руководства для FreeBSD, OpenBSD, NetBSD и DragonFly BSD» . Проверено 25 декабря 2014 г.
- ^ Муренин, Константин А. (23 февраля 2013 г.). «mdoc.su.nginx.conf» . Проверено 25 декабря 2014 г.
- ^ «Метатег HTML» . www.w3schools.com .
- ^ «Исследование динамических документов» . 2 августа 2002 г. Архивировано из оригинала 2 августа 2002 г.
{{cite web}}: CS1 maint: bot: исходный статус URL неизвестен ( ссылка ) - ^ «Google и Yahoo принимают незадерживаемые метаобновления как 301 редирект» . Брошюры Себастьяна. 3 сентября 2007 г.
- ^ «Руководство по обеспечению доступности веб-контента 1.0» . www.w3.org .
- ^ Команда, QA. «Использовать стандартные перенаправления» . www.w3.org .
- ^ «Основные методы обеспечения доступности веб-контента 1.0» . www.w3.org .
- ^ «Кроссбраузерный генератор перенаправления URL-адресов на стороне клиента» . Инсайдерская зона. Архивировано из оригинала 26 июля 2020 года . Проверено 27 августа 2015 г.
- ^ Аарон Эмиг (19 января 2005 г.). «Технология защиты от фишинга». Архивировано 27 сентября 2007 г. в Wayback Machine (PDF). Радикс Лабс.
- ^ «HTML 5.2: 11. Устаревшие функции» . www.w3.org .
- ^ Шварц, Барри (18 декабря 2007 г.). «Двойные редиректы могут потребовать от Google больше времени, чтобы их обработать» . Круглый стол по поисковым системам . Проверено 28 января 2024 г.
- ^ Рой Т. Филдинг ; Джулиан Ф. Решке, ред. (2014). «Перенаправление 3хх» . Протокол передачи гипертекста (HTTP/1.1): семантика и содержание . IETF . п. 54. сек. 6.4. дои : 10.17487/RFC7231 . РФК 7231 .
- ^ «Чистая прибыль крошечной тихоокеанской страны» . Новости Би-би-си . 14 сентября 2007 г. Архивировано из оригинала 12 мая 2014 г. Проверено 27 мая 2010 г.
- ^ Перейти обратно: а б Инноченти, Томмазо; Голинелли, Маттео; Онарлиоглу, Каан; Мирхейдари, Али; Криспо, Бруно; Кирда, Энгин (4 декабря 2023 г.). «Проверка URI перенаправления OAuth 2.0 в буквальном смысле не соответствует требованиям» . Ежегодная конференция по приложениям компьютерной безопасности . АКСАК '23. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. стр. 256–267. дои : 10.1145/3627106.3627140 . HDL : 11572/399070 . ISBN 979-8-4007-0886-2 .
- ^ «Открыть перенаправление» . ОВАСП. 16 марта 2014 года . Проверено 21 декабря 2014 г.
- ^ «Скрытое перенаправление» . Тетраф. 1 мая 2014 года . Проверено 21 декабря 2014 г.
- ^ «Обнаружен серьезный недостаток безопасности в OAuth, OpenID» . CNET. 2 мая 2014 года . Проверено 21 декабря 2014 г.
- ^ Майк Уильямс (5 июня 2022 г.). «Что такое уязвимость Open Redirect, почему она опасна и как обезопасить себя?» . ТехРадар . Проверено 8 апреля 2024 г.
- ^ «CWE — CWE-601: перенаправление URL-адреса на ненадежный сайт («Открытое перенаправление») (4.14)» . cwe.mitre.org . Проверено 8 апреля 2024 г.
- ^ Книттель, Лукас; Майнка, Кристиан; Нимитц, Маркус; Носс, Доминик Тревор; Швенк, Йорг (13 ноября 2021 г.). «XSinator.com: от формальной модели к автоматической оценке межсайтовых утечек в веб-браузерах» . Материалы конференции ACM SIGSAC 2021 года по компьютерной и коммуникационной безопасности . ККС '21. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. стр. 1771–1788. дои : 10.1145/3460120.3484739 . ISBN 978-1-4503-8454-4 .
Внешние ссылки
[ редактировать ]- Сопоставление URL-адресов с местоположениями файловой системы — HTTP-сервер Apache версии 2.4
- Классификация спама с перенаправлением JavaScript (Microsoft Live Labs)
- Уязвимости безопасности в перенаправителях URL-адресов Классификация угроз Консорциума безопасности веб-приложений