Открытые редиректы: уязвимость, используемая мошенниками
Открытый редирект (open redirect) — это уязвимость веб-приложения, при которой сайт позволяет перенаправить пользователя на произвольный внешний URL по параметру из ссылки. Сама по себе это обычно низкоприоритетная уязвимость, но мошенники превратили её в мощный инструмент: ссылка начинается с доверенного домена — банка, поисковика, корпоративного портала — но ведёт куда угодно.
Как работает открытый редирект
Представьте себе функцию на сайте: после успешной авторизации пользователь перенаправляется на страницу, которую он хотел посетить. URL может выглядеть так:
https://bank.ru/login?next=/account/dashboard
Если разработчики не ограничили значение параметра next только внутренними путями, злоумышленник может использовать:
https://bank.ru/login?next=https://phishing-bank.ru/steal
После входа в банк пользователь будет перенаправлен на phishing-bank.ru. При этом ссылка, которую жертва получила в письме, начинается с bank.ru — доверенного домена.
Типичные параметры открытых редиректов
Следующие параметры в URL часто указывают на механизм редиректа — и потенциально на уязвимость:
- ?url=
- ?redirect=
- ?next=
- ?return=
- ?returnUrl=
- ?continue=
- ?r=
- ?go=
- ?to=
Если значение такого параметра начинается с http:// или https:// — это потенциально открытый редирект. Проверьте, куда ведёт этот URL.
Реальные примеры использования в фишинге
Google как прикрытие
Google имеет множество открытых редиректов в своих сервисах для легитимных целей. Мошенники использовали URL вида:
https://accounts.google.com/ServiceLogin?continue=https://phishing.ru/
Письмо содержит ссылку на google.com — антифишинговый фильтр её пропускает. После перехода Google перенаправляет на phishing.ru.
Корпоративные порталы
Корпоративные системы (SSO, внутренние порталы) особенно уязвимы, так как разработчики часто не думают о безопасности внутренних перенаправлений. Фишинговые письма «от имени Microsoft» или «от IT-отдела» используют корпоративные URL с открытым редиректом.
Маркетинговые сервисы
Серверы отслеживания кликов в email-маркетинге (типа tracking.company.com/click?url=...) иногда становятся векторами атаки. Письмо выглядит как официальная рассылка, ссылка начинается с корпоративного домена — но url= содержит фишинговый сайт.
Как распознать атаку через открытый редирект
- В URL присутствует один из параметров редиректа (url=, redirect=, continue= и т.д.)
- Значение параметра — внешний URL (начинается с http:// или https://)
- Конечный домен в значении параметра — незнакомый или подозрительный
Всегда проверяйте не только первый домен в ссылке, но и значения всех параметров редиректа. 2check.click анализирует параметры URL и предупреждает об открытых редиректах на потенциально вредоносные сайты.
Почему это сложно исправить
Открытые редиректы существуют во многих крупных сервисах, потому что их функциональность нужна (например, перенаправление после авторизации). Полностью блокировать внешние URL нельзя — это ломает сценарии OAuth. Правильное решение — белый список разрешённых доменов. Но многие команды не реализуют это должным образом.
Проверьте подозрительную ссылку
Вставьте URL, SMS или QR-код в 2check.click — сервис проверит домен, редиректы, возраст домена и другие признаки фишинга.
Часто задаваемые вопросы
Являются ли открытые редиректы серьёзной уязвимостью?
Сами по себе они считаются уязвимостью средней/низкой серьёзности. Но в контексте фишинга они значительно повышают убедительность атаки, делая ссылку трудно отличимой от легитимной.
Как проверить, является ли редирект открытым?
Посмотрите на параметр url= или redirect= в ссылке. Если его значение — произвольный внешний URL и сайт действительно перенаправляет туда — это открытый редирект.
Может ли открытый редирект использоваться для установки вредоносного ПО?
Да. Если конечная страница содержит drive-by загрузку или обманом провоцирует установку «обновления», открытый редирект на легитимном домене повышает доверие жертвы к предложению.
Как разработчики могут защититься от открытых редиректов?
Использовать белый список разрешённых доменов, разрешать только относительные пути (не начинающиеся с http://), валидировать значение параметра на стороне сервера.
Примеры крупных сервисов с открытыми редиректами?
Открытые редиректы находили в Google, Microsoft, Amazon и многих других. Большинство из них были закрыты после ответственного раскрытия, но новые периодически обнаруживаются.