Открытый редирект (Open Redirect): как мошенники маскируют фишинговые ссылки
Открытый редирект возникает, когда сайт перенаправляет пользователя на внешний адрес, указанный в параметре запроса (?url=https://evil.com), без валидации домена.
Злоумышленники используют ваш авторитетный домен в фишинговых письмах, чтобы обойти антиспам-фильтры почтовых провайдеров.
Степень критичности и чем опасна уязвимость
Использование вашего домена в мошеннических кампаниях, ведущее к блокировке сайта почтовыми сервисами и антивирусами.
Как наш сканер находит эту уязвимость
Site Check проверяет параметры перенаправления на наличие открытого редиректа на произвольные внешние домены.
Тестирование прикладных уязвимостей веб-приложения базируется на пассивном анализе структуры параметров, форм и рефлексии входных данных без передачи вредоносных деструктивных эксплойтов. Это позволяет выявить риски XSS, CSRF, Open Redirect и инъекций без деградации производительности приложения.
Как устранить уязвимость (Пошаговое руководство)
Для ликвидации риска выполните следующие действия в конфигурации вашего сервера или приложения:
// Разрешайте только относительные редиректы:
const redirectUrl = req.query.url;
if (!redirectUrl.startsWith('/') || redirectUrl.startsWith('//')) {
return res.redirect('/');
}
- Разрешайте перенаправления только на относительные пути внутри сайта.
- Для внешних ссылок ведите строгий белый список разрешенных доменов партнеров.
Анатомия атаки и реальные последствия для проекта
Параметры перенаправления (?returnUrl=https://evil.com) без валидации используются в фишинговых рассылках: ссылка ведет на доверенный домен, но сразу перенаправляет жертву на поддельный сайт сбора паролей.
Влияние на соответствие стандартам: Нарушение требований безопасности стандартов OWASP Top 10 (A05:2021 Security Misconfiguration), ISO/IEC 27001 и отраслевых норм 152-ФЗ.
Матрица эшелонированной защиты (Defense-in-Depth)
| Уровень защиты | Техническое действие | Инструмент / Механизм |
|---|---|---|
| Периметр веб-сервера (Nginx / Edge) | Применение изолирующих правил блокировки для маршрутов, связанных с open-redirect | Nginx Security Directives |
| Среда исполнения и конфигурация | Отключение отладочных механизмов и разграничение прав доступа к компоненту open-redirect | Runtime Security Hardening |
| Пайплайн DevSecOps контроля | Автоматическое тестирование конфигурации open-redirect в CI/CD пайплайне при каждом релизе | Site Check Security Gate |
Верификация устранения: команды для быстрой проверки
После внесения изменений в настройки сервера или исходный код приложения проверьте отсутствие уязвимости с помощью терминальных утилит:
curl -I -s "https://ваш-домен.com/login?redirect=https://evil.com" | grep -i "Location: https://evil.com"
# Перенаправление на внешние домены должно блокироваться
Рекомендации DevSecOps для безопасного развертывания
Разрешайте редиректы только на относительные пути (/dashboard), начинающиеся с одного слэша, или сверяйте URL с белым списком доменов.
- ✓ Использовать параметризованные запросы и подготовленные выражения во всех SQL-запросах
- ✓ Выполнять контекстную санитизацию и экранирование пользовательского ввода во фронтенде
- ✓ Внедрить валидацию CSRF-токенов для всех изменяющих состояние POST/PUT запросов
- ✓ Ограничить внешние перенаправления белым списком разрешённых доменов
Часто задаваемые вопросы по устранению
Прикладные уязвимости логики кода (OWASP Top 10) требуют комплексного подхода: использование параметризованных ORM-запросов, контекстное экранирование HTML-шаблонизаторов, внедрение анти-CSRF токенов и интеграция Web Application Firewall (WAF) на внешнем шлюзе.
Для предотвращения вектора «Открытый редирект (Open Redirect): как мошенники маскируют фишинговые ссылки» зафиксируйте проверочные правила в CI/CD пайплайне и настройте непрерывный мониторинг внешнего периметра через Site Check.