Открытый редирект — это когда URL, начинающийся с вашего настоящего домена, отправляет посетителя на совершенно другой сайт. Вот как он работает и как его надёжно предотвратить (без шагов атаки).
Почему это опасно
Главный вред — заимствование доверия к вашему домену.
| Как злоупотребляют | Что происходит |
|---|---|
| Фишинг через ваш домен | Ссылка начинается с настоящего домена → пользователи и фильтры доверяют ей → переход на поддельный сайт |
| Перехват потока аутентификации | Подмена цели редиректа в потоках в стиле OAuth, чтобы перехватить токен/код |
| Усиление других багов | В сочетании с SSRF или XSS для расширения ущерба |
Почему это работает
Это встречается в функциях вроде «вернуть пользователя туда, где он был, после входа», где URL возврата принимается на доверии и используется как есть. «Начало» URL, которое видит пользователь, — настоящий домен, поэтому усомниться до самого конца сложно.
Защита: не принимайте внешние URL
Разрешайте только относительные пути (самое важное)
Принимайте цели возврата вроде /dashboard — только относительные пути — и отклоняйте полные URL (начинающиеся с http:// или //). Не оставляйте пользователю возможности задать домен назначения.
Сверяйте с allowlist
Если нужны динамические цели, разрешайте только записи из фиксированного набора известных назначений (карты). Всё остальное откатывается на страницу по умолчанию.
Не полагайтесь на проверки строк
//evil, обратные слеши, @ и многократное кодирование обходят наивные фильтры. Измените то, что вы принимаете (относительные пути + allowlist), вместо латания фильтров.
Если переход на внешний сайт необходим — сделайте его явным
Когда внешние редиректы задуманы намеренно, показывайте промежуточную страницу («Вы переходите на внешний сайт»). Не перенаправляйте молча.
Мнение этого сайта: сам по себе оценивается как «низкий», но серьёзен в сочетании с фишингом
Открытые редиректы часто оценивают как низкий риск сам по себе, но поскольку злоумышленники могут заимствовать доверие к вашему домену, в сочетании с фишингом или перехватом аутентификации они становятся серьёзными. Поэтому решение на уровне проектирования (относительные пути + allowlist) эффективно устраняет причину. Это перекликается с SSRF (заставить сервер соединиться куда угодно): оба разделяют принцип защиты — никогда не позволять пользователю решать, куда идти.
Открытый редирект, SSRF и фишинг
Открытый редирект — не столько атака сама по себе, сколько изъян, делающий другие атаки убедительнее. Рядом со смежными терминами видно его место.
| Термин | Что происходит | Кто исправляет |
|---|---|---|
| Открытый редирект | URL на настоящем сайте перенаправляет браузер пользователя на внешний сайт | Разработчики сайта с функцией редиректа |
| SSRF | Не браузер, а сервер отправляет запрос по переданному ему адресу | Разработчики сайта с функцией загрузки URL |
| Фишинг | Поддельный сайт заставляет вводить логины, пароли или данные карт | Пользователи, получатели почты и организация, от имени которой действуют |
Когда фишинговая ссылка может использовать настоящий домен, её труднее распознать и пользователям, и почтовым фильтрам. Устранив открытые редиректы, вы не дадите использовать свой домен в мошенничестве.
Пример: где это важнее всего — интеграции входа (OAuth)
Открытые редиректы важнее всего рядом с интеграциями входа (OAuth). После авторизации пользователя отправляют обратно на зарегистрированный redirect URI вместе с кодом авторизации или токеном. Если на сайте, куда он возвращается, есть открытый редирект, код или токен могут уйти дальше на внешний сайт.
Поэтому рекомендации по безопасности OAuth 2.0 (RFC 9700, январь 2025 г.) требуют двух вещей.
- Сервер авторизации сравнивает redirect URI с заранее зарегистрированными по точному совпадению
- Ни клиенты, ни серверы авторизации не держат страниц, перенаправляющих на произвольный URL из параметра запроса
Открытые редиректы классифицируются как CWE-601. Сами по себе они редко получают высокую оценку серьёзности, но рядом с интеграцией входа становятся серьёзной проблемой.
Насколько это серьёзно
Сам по себе открытый редирект обычно оценивается как средний. Часто встречающаяся оценка — CVSS 3.1 6.1.
- Пользователь должен открыть ссылку (UI:R)
- Последствие — отправка пользователей на другой сайт; прочитать данные сайта напрямую это не позволяет
- Поскольку последствия выходят за пределы сайта с редиректом, это оценивается как изменение области (S:C)
Не откладывайте исправление из-за цифры. Исправляйте в первую очередь, если редирект находится на пути возврата интеграции входа или уже используется в фишинге. Чтобы оценить свой случай, воспользуйтесь калькулятором CVSS.
Безопасные помощники, которые уже есть в вашем фреймворке
Функции фреймворка реже упускают случаи, чем собственные проверки строк. Два распространённых примера:
| Фреймворк | Помощник | Что делает |
|---|---|---|
| Ruby on Rails | Поведение redirect_to по умолчанию и url_from | По умолчанию блокирует редиректы на другие хосты; чтобы отправить пользователя на внешний сайт, нужно явно указать allow_other_host: true. url_from возвращает URL, только если он на том же хосте, иначе nil |
| ASP.NET Core | LocalRedirect и Url.IsLocalUrl | Перенаправляет только на URL в пределах того же сайта и выбрасывает исключение для внешнего URL |
Документация Rails предупреждает, что даже с allow_other_host: true передавать параметр от пользователя напрямую небезопасно. Добавляя функцию внешнего редиректа, избегайте такого сочетания.
Как проверить свой сайт
Найдите параметры, принимающие назначение
Поищите в коде и списке URL параметры с именами вроде next, url, redirect, return_to, continue или callback и проверьте, не передаются ли они прямо в редирект.
Проверьте, как валидируются назначения
Посмотрите, не опирается ли проверка на сравнение префикса строки или «начинается ли с http». Вместо этого разбирайте URL парсером на схему, хост и порт и сверяйте с allowlist или используйте безопасные помощники фреймворка (например, LocalRedirect в ASP.NET Core).
Пересмотрите регистрации интеграций входа
В настройках OAuth или SSO проверьте, что в зарегистрированных redirect URI нет подстановочных знаков и старых ненужных URL.
Подумайте о выборе назначения по ID
Если внешний редирект необходим, принимайте короткий ID, а не сам URL, и ищите назначение в таблице на сервере. Такой подход рекомендует OWASP.
Ищите внешние редиректы в журналах доступа
Поищите в журналах доступа запросы, где параметр назначения содержит имя хоста, отличное от вашего. Если такие есть, проверьте, действительно ли этот редирект уводит людей на внешний сайт, и считайте это признаком того, что кто-то может распространять такие ссылки.
Источники (первичные)
- OWASP, «Unvalidated Redirects and Forwards Cheat Sheet» — cheatsheetseries.owasp.org (ID с сопоставлением на сервере, проверка разобранных URL по allowlist, страницы предупреждения)
- IETF RFC 9700, «Best Current Practice for OAuth 2.0 Security» (январь 2025 г.) — datatracker.ietf.org (точное совпадение redirect URI, запрет открытых редиректоров)
- Ruby on Rails API, «ActionController::Redirecting» — api.rubyonrails.org (защита по умолчанию от редиректов на другие хосты,
allow_other_host,url_from) - Microsoft, «Prevent open redirect attacks in ASP.NET Core» — learn.microsoft.com (
LocalRedirect,IsLocalUrl, журналирование нелокальных URL) - MITRE, «CWE-601: URL Redirection to Untrusted Site ('Open Redirect')» — cwe.mitre.org
Читать дальше
- Глоссарий: Что такое SSRF · Что такое XSS · Что такое фишинг · Что такое CVSS
- Основы: Основы безопасности