Редиректа с HTTP на HTTPS недостаточно: какие риски остаются и как закрыть их полностью
Фраза "у нас настроен редирект с HTTP на HTTPS" часто звучит как финальный ответ на замечание аудитора. Однако перенаправление не делает первоначальный запрос защищённым. Оно лишь сообщает клиенту, куда обратиться дальше, когда HTTP-соединение уже состоялось.
Именно поэтому настройка редиректа с HTTP на HTTPS не всегда закрывает требования безопасности. Например, сервер может отвечать кодом 301 на запрос `http://example.com/orders/48213/invoice`, но сам запрос уже покинул устройство. В нём могли находиться путь, параметры, служебные заголовки и Cookie.
Проблема стала менее заметной благодаря современным браузерам. Chrome, Firefox и Safari во многих сценариях самостоятельно предпочитают HTTPS. Но это не означает, что HTTP исчез полностью. Открытый запрос по-прежнему могут отправить:
- ссылки с явно указанной схемой `http://` в письмах, документации и старых закладках;
- `curl`, скрипты и программные HTTP-клиенты;
- встроенные браузеры мобильных приложений;
- устаревшие устройства и специализированное оборудование;
- интеграции, которые однажды настроили на HTTP и больше не пересматривали;
- механизм отката, если обращение к HTTPS завершилось неудачно.
Какие данные уходят до перенаправления
HTTP-запрос не шифруется. Наблюдатель в открытой Wi-Fi-сети, злоумышленник на скомпрометированном роутере или промежуточный узел может увидеть полный URL, включая путь и query-параметры. Адрес `/orders/48213/invoice` способен раскрыть номер заказа, тип документа или внутреннюю структуру приложения.
Отдельный риск создают Cookie без атрибута `Secure`. Такая cookie отправляется и по незашифрованному соединению. Если в ней находится идентификатор сессии, он может оказаться доступен постороннему лицу уже в первом HTTP-запросе.
Есть и ещё одна угроза: злоумышленник может не просто прочитать обращение, а ответить на него раньше настоящего сервера. Клиент получит поддельную страницу, фальшивый редирект или предложение перейти на похожий домен. Пока TLS-сеанс не установлен, у клиента нет надёжного способа проверить подлинность ответа.
Поэтому проверка безопасности HTTPS и SSL сертификата должна учитывать не только корректность сертификата и наличие шифрования, но и поведение сервиса до начала TLS-соединения. Важно понимать: правильный HTTPS-ответ не отменяет того, что произошло на предыдущем этапе.
Как работает HSTS
Заголовок `Strict-Transport-Security` заставляет браузер обращаться к сайту только по HTTPS. Например:
```http
Strict-Transport-Security: max-age=31536000
```
Значение `31536000` соответствует одному году. После успешного визита по HTTPS браузер сохраняет правило и автоматически заменяет HTTP на HTTPS ещё до отправки сетевого запроса.
Но HSTS защищает не первый визит, а последующие. Заголовок передаётся только через HTTPS, поэтому новому браузеру, очищенному профилю или новому устройству сначала нужно получить его безопасным способом. До этого первоначальное обращение по HTTP всё ещё возможно.
Директива `includeSubDomains` расширяет действие политики на поддомены:
```http
Strict-Transport-Security: max-age=31536000; includeSubDomains
```
Это позволяет закрыть не только `example.com`, но и `auth.example.com`, `api.example.com`, `mail.example.com` и другие узлы. Одновременно такая настройка требует осторожности: под действие политики попадут забытые, экспериментальные и будущие поддомены. Если хотя бы один из них не поддерживает HTTPS, пользователи могут потерять доступ к сервису.
В рамках защиты внутренних сервисов от HTTP доступа необходимо проверить не только основной сайт, но и административные панели, API, панели мониторинга, тестовые окружения и служебные домены. Нередко публичный веб-сайт защищён правильно, а внутренний сервис продолжает принимать незашифрованные обращения.
Предзагрузка HSTS: сильнее, но не всегда безопаснее
HSTS preload решает проблему первого визита. Список доменов заранее встроен в браузер, поэтому для включённого в него домена клиент сразу использует HTTPS. Обращения к HTTP-порту не происходит вообще.
Для попадания в список обычно требуются следующие условия:
- HTTPS должен работать на основном домене;
- сертификат обязан быть действующим;
- заголовок HSTS должен иметь `max-age` не менее года;
- должна присутствовать директива `includeSubDomains`;
- необходимо добавить `preload`;
- HTTP-запрос должен перенаправляться на HTTPS того же хоста.
Последнее требование становится причиной большого числа отказов. Если запрос с 80-го порта уходит не на HTTPS того же домена, а, например, на другой адрес или отдельную страницу, заявка может быть отклонена.
Проверить состояние домена можно через сервис проверки списка предварительной загрузки. Статус `preloaded` означает, что домен уже включён в браузерный список, `pending` - заявка принята, но защита пока не попала в версии браузеров, а `unknown` - домен отсутствует в перечне. Подробный разбор этой процедуры и типичных ошибок доступен в материале о предзагрузке HSTS и защите первого HTTPS-визита.
Почему с preload нельзя спешить
Предварительная загрузка - не обычный переключатель, который можно мгновенно отключить. Список распространяется вместе с обновлениями браузеров. Поэтому удаление домена происходит с задержкой и зависит от того, когда пользователи обновят программное обеспечение.
Типовая последовательность отключения выглядит так:
1. убрать `preload` из заголовка;
2. временно установить `max-age=0`;
3. подать запрос на исключение домена;
4. дождаться перевода заявки в состояние удаления;
5. дождаться обновления браузеров у пользователей.
Даже после выполнения этих шагов часть клиентов некоторое время продолжит принудительно использовать HTTPS. В результате ошибочная настройка может сделать недоступным сервис, который ещё не готов к обязательному шифрованию.
Перед включением preload стоит провести аудит безопасности веб-приложений и API. Нужно составить перечень всех поддоменов, проверить сертификаты, наличие HTTPS на каждом сервисе, корректность редиректов и работу нестандартных портов. Отдельно следует убедиться, что сторонние системы, вебхуки и старые интеграции не зависят от HTTP.
Что проверить перед переходом
Полезно протестировать сайт в чистом профиле браузера, через командную строку и с разных сетей. Проверка должна включать отправку запросов на HTTP, анализ заголовков, поведение при обращении к поддоменам и реакцию API-клиентов.
Cookie сессий следует пометить атрибутами `Secure`, `HttpOnly` и подходящим `SameSite`. Пароли, токены и персональные данные нельзя передавать через URL, поскольку адреса могут сохраняться в журналах, истории браузера и системах мониторинга.
Кроме того, важно закрыть прямой доступ к внутренним интерфейсам на уровне сети: ограничить порты, использовать VPN или защищённый шлюз, настроить сетевые политики и удалить неиспользуемые точки входа. Настройка HTTPS для корпоративных сервисов должна быть частью общей модели защиты, а не отдельной задачей для публичного сайта.
Итог прост: редирект помогает совместимости, но не заменяет шифрование. HSTS защищает повторные обращения, а preload - первый визит, однако требует тщательной инвентаризации инфраструктуры и готовности жить с долгосрочными последствиями. Надёжная защита начинается там, где команда проверяет не только код ответа 301, но и весь путь запроса - от клиента до конечного сервиса.
