Отсутствие редиректа с HTTP на HTTPS: риски перехвата трафика
Протокол HTTP передает трафик в незашифрованном виде. Если сайт доступен по HTTP без автоматического 301-редиректа на HTTPS, данные передаются открытым текстом.
Злоумышленники в публичных Wi-Fi сетях могут перехватывать сессионные cookie, пароли и модифицировать содержимое веб-страниц (атаки Man-in-the-Middle).
Степень критичности и чем опасна уязвимость
Перехват логинов, паролей пользователей и пессимизация сайта в поисковой выдаче Google и Яндекса.
Как наш сканер находит эту уязвимость
Site Check делает запрос по протоколу HTTP (порт 80) и валидирует наличие постоянного редиректа (301 Moved Permanently) на безопасный протокол HTTPS.
Диагностика сетевых заголовков и серверных политик выполняется сбором и парсингом HTTP response headers на корневом и вспомогательных путях. Оценивается присутствие политик Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, а также атрибутов безопасности куки-файлов (HttpOnly, Secure, SameSite).
Как устранить уязвимость (Пошаговое руководство)
Для ликвидации риска выполните следующие действия в конфигурации вашего сервера или приложения:
server {
listen 80;
server_name your-domain.com www.your-domain.com;
return 301 https://$host$request_uri;
}
- Настройте постоянный 301-редирект с HTTP на HTTPS для всех портов и поддоменов.
- Включите заголовок HSTS (Strict-Transport-Security).
Анатомия атаки и реальные последствия для проекта
При отсутствии принудительного редиректа на HTTPS трафик пользователя в открытых Wi-Fi сетях может быть перехвачен через атаку Man-in-the-Middle (MitM) с помощью утилит sslstrip, перехватывающих пароли и куки сессий.
Влияние на соответствие стандартам: Нарушение требований безопасности стандартов OWASP Top 10 (A05:2021 Security Misconfiguration), ISO/IEC 27001 и отраслевых норм 152-ФЗ.
Матрица эшелонированной защиты (Defense-in-Depth)
| Уровень защиты | Техническое действие | Инструмент / Механизм |
|---|---|---|
| Периметр веб-сервера (Nginx / Edge) | Применение изолирующих правил блокировки для маршрутов, связанных с http-to-https-redirect | Nginx Security Directives |
| Среда исполнения и конфигурация | Отключение отладочных механизмов и разграничение прав доступа к компоненту http-to-https-redirect | Runtime Security Hardening |
| Пайплайн DevSecOps контроля | Автоматическое тестирование конфигурации http-to-https-redirect в CI/CD пайплайне при каждом релизе | Site Check Security Gate |
Верификация устранения: команды для быстрой проверки
После внесения изменений в настройки сервера или исходный код приложения проверьте отсутствие уязвимости с помощью терминальных утилит:
curl -I -s http://ваш-домен.com/ | grep "Location:"
# Должен возвращать редирект 301 на https://
Рекомендации DevSecOps для безопасного развертывания
Настройте в Nginx отдельный блок server на 80 порту с return 301 https://$host$request_uri; и активируйте заголовок HSTS.
- ✓ Внедрить строгую политику Content-Security-Policy без небезопасных инлайн-скриптов
- ✓ Включить заголовок HSTS с директивой includeSubDomains и сроком не менее 1 года
- ✓ Установить флаги Secure, HttpOnly и SameSite=Lax для всех авторизационных куки
- ✓ Настроить редирект HTTP на HTTPS с корректным статус-кодом 301 Permanent
Часто задаваемые вопросы по устранению
Корректно настроенные заголовки безопасности формируют первый эшелон браузерной защиты клиентов. Отсутствие современных директив CSP и HSTS оставляет пользователей беззащитными перед атаками типа Clickjacking, MIME-sniffing и перехватом трафика в небезопасных сетях Wi-Fi.
Для предотвращения вектора «Отсутствие редиректа с HTTP на HTTPS: риски перехвата трафика» зафиксируйте проверочные правила в CI/CD пайплайне и настройте непрерывный мониторинг внешнего периметра через Site Check.