Open Redirect (произвольный редирект)
Уязвимость веб-приложения, позволяющая использовать доверенный домен сайта как промежуточную ступень для перенаправления пользователя на произвольный внешний адрес — без ведома владельца сайта и без предупреждения пользователя.
Что такое Open Redirect
Open Redirect (открытый, или произвольный редирект) — уязвимость, при которой сервер принимает целевой URL из параметра запроса и выполняет перенаправление без проверки допустимости адреса назначения. Классический пример:
https://site.ru/go?url=https://evil.comСервер читает параметр url и слепо отдаёт 302 Found на evil.com. Пользователь видит в адресной строке знакомый домен site.ru, кликает — и оказывается на вредоносной странице. Психологически это работает именно потому, что доверие к бренду переносится на конечный адрес: «ссылка же ведёт на сайт банка...».
OWASP относит произвольные редиректы к категории A01:2021 (Broken Access Control) в своём Top 10. Ранее уязвимость выделялась в отдельный пункт A10. Bug bounty за обнаружение — от 200 до 2000 USD в зависимости от критичности сервиса.
Для сервисов коротких ссылок и динамических QR-кодов уязвимость особенно опасна: весь смысл сервиса — в редиректе, и стоит убрать проверку назначения, как любой может превратить доверенный домен в фишинговый трамплин.
Как эксплуатируется через QR
Сценарий атаки через QR-код строится на трёх шагах.
- Находка уязвимости. Злоумышленник обнаруживает, что у популярного сервиса — платёжной системы, маркетплейса, банка — есть открытый редирект вида
/redirect?to=. Иногда достаточно проверить URL из письма о сбросе пароля. - Создание QR. Атакующий генерирует QR с адресом
https://доверенный-банк.ru/go?url=https://fake-bank.ru/loginи печатает его на листовке, наклейке или вставляет в PDF-квитанцию. - Жертва сканирует. Preview в смартфоне показывает
доверенный-банк.ru— вопросов не возникает. После сканирования браузер делает запрос к настоящему серверу банка, который послушно перенаправляет на фейк-страницу. В адресной строке ужеfake-bank.ru, но пользователь привык кликать «разрешить» не глядя.
В отличие от грубой подделки, Open Redirect-атака использует легитимную инфраструктуру жертвы, поэтому репутационные и антифрод-фильтры её часто пропускают: домен первого хопа — реальный, чистый, с валидным TLS. Подробнее о том, как QR-фишинг использует доверие к знакомым брендам, — в отдельном термине.
Методы защиты
Три подхода применяются в современных сервисах — от простейшего к надёжному.
- Whitelist допустимых доменов. Самый простой и эффективный метод: сервер разрешает редиректить только на заранее одобренный список доменов. Всё, чего нет в списке, — отклоняется с ошибкой 400 или редиректом на главную страницу. Подходит для сервисов с фиксированным набором назначений (партнёрские программы, SSO).
- Signed redirects (HMAC-подписи). URL-параметр снабжается криптографической подписью:
/go?url=https://example.com&sig=abc123. Без знания секретного ключа подпись не подделать. Сервер проверяет подпись до редиректа. Используется там, где список назначений динамичен — например, в сервисах коротких ссылок. - Интерстициал «предупреждение о переходе». Вместо мгновенного редиректа сервер показывает промежуточную страницу: «Вы переходите на внешний сайт example.com. Продолжить?». Снижает UX, но даёт пользователю осознанный момент выбора. Применяется Telegram, Wikipedia, некоторыми банками.
Комбинация whitelist + signed redirects закрывает атаку почти полностью. Если ваш сервис строится на коротких ссылках, обе меры стоит применять одновременно.
Частые вопросы
Чем Open Redirect отличается от обычного редиректа?
Обычный редирект контролируется разработчиком и ведёт на фиксированный адрес, прописанный в коде. Open Redirect берёт цель из пользовательского ввода (параметр URL, заголовок Referer, форма) и выполняет перенаправление без валидации. Злоумышленник может подставить любой адрес, и сервер его выполнит — в этом и есть суть уязвимости.
Помогает ли HTTPS защититься от Open Redirect?
Нет. HTTPS шифрует трафик и подтверждает подлинность сертификата домена, но не контролирует логику редиректов внутри приложения. Сайт с зелёным замком может иметь открытый редирект. Проверяйте конечный домен в адресной строке после каждого перехода, особенно если сканировали QR.
Как проверить, есть ли Open Redirect на моём сайте?
Найдите все параметры, принимающие URL: redirect_to, next, url, return, goto, target. Попробуйте передать внешний домен: ?next=https://google.com. Если сервер вернул 302 на Google — уязвимость есть. Дополнительно проверьте заголовок Referer и POST-параметры форм входа. Автоматизировать проверку можно через OWASP ZAP или Burp Suite.
Какой штраф грозит компании, если уязвимость использовали для фишинга?
Прямой административной ответственности за наличие уязвимости в РФ нет. Но если через Open Redirect на вашем домене был реализован фишинг против клиентов — высока репутационная и гражданская ответственность: иски пострадавших, жалобы в ЦБ (для финансовых организаций), блокировка домена по 149-ФЗ и внесение в реестр Роскомнадзора.
Можно ли обнаружить Open Redirect-атаку через QR по логам?
Да. Признаки в логах: аномальный рост запросов к редирект-эндпоинту, параметры url с внешними доменами, источник трафика — мобильные User-Agent (сканирование QR). Настройте алерт на запросы к /go, /redirect с параметрами, содержащими http:// или https:// вне whitelist. WAF-правила класса OWASP CRS покрывают базовые сигнатуры.
Что такое «malicious URL через Open Redirect» и чем это хуже прямой вредоносной ссылки?
При прямом вредоносном URL антифрод и браузерные фильтры видят домен назначения и могут заблокировать его по репутации. При Open Redirect первый хоп — чистый доверенный домен, блокировка не срабатывает. Пользователь и защитные системы получают сигнал о безопасности в момент, когда переход уже происходит. Подробнее о типах угроз — в термине вредоносный URL.