Сайт доступен по HTTPS, но пользователь впервые открывает его по HTTP. Как проверить защиту от атаки понижения соединения?
Проверить нужно наличие и корректность механизма HSTS: после защищённого ответа браузер должен получить заголовок Strict-Transport-Security, а последующие обращения по HTTP должны автоматически преобразовываться в HTTPS до отправки запроса. В чистом браузере первый HTTP-запрос всё ещё может быть уязвим, если домен заранее не включён в HSTS-пр preload-список.
HSTS появился для решения проблемы атак типа SSL stripping. При такой атаке злоумышленник не ломает HTTPS, а не даёт пользователю перейти на него, сохраняя для клиента HTTP-соединение и передавая запросы к серверу по защищённому каналу самостоятельно.
Идея HSTS состоит в том, чтобы браузер запомнил требование использовать только HTTPS. После этого HTTP не считается допустимым вариантом подключения к домену.
Одного перенаправления с HTTP на HTTPS недостаточно. До получения перенаправления пользователь уже может отправить по HTTP идентификатор сессии, данные формы или другой чувствительный параметр.
Тестировщик должен оценить не только факт перенаправления, но и поведение браузера до отправки HTTP-запроса. Ошибки в области действия политики могут оставить без защиты поддомены или отдельные точки входа приложения.
Проверку проводят в чистом профиле браузера и в уже обученном политике профиле. Сначала подтверждают, что HTTPS-ответ содержит Strict-Transport-Security с положительным сроком действия. Заголовок, переданный только по HTTP, браузер не должен считать основанием для включения HSTS, поскольку такой канал нельзя считать доверенным.
Затем после получения политики обращаются к HTTP-версии сайта. В защищённом сценарии браузер самостоятельно заменяет схему на HTTPS и не отправляет исходный HTTP-запрос в сеть. Это отличается от обычного серверного перенаправления, которое происходит только после получения HTTP-запроса.
Нужно проверить область действия директив. includeSubDomains распространяет правило на поддомены, но применять его следует только если все такие поддомены действительно поддерживают HTTPS. Иначе легитимные сервисы могут стать недоступными.
Для защиты самого первого обращения используют предварительное включение домена в список HSTS preload браузеров при выполнении требований конкретного списка. Это уменьшает риск первой HTTP-сессии, но создаёт операционный компромисс: ошибочное включение или слишком долгий срок действия политики усложняют возврат к HTTP.
HSTS не заменяет настройку сертификатов, безопасные cookie и контроль смешанного содержимого. Он защищает выбор протокола между браузером и доменом, но не устраняет уязвимости самого приложения или компрометацию доверенного HTTPS-канала.
Интернет-магазин перенаправлял все HTTP-запросы на HTTPS, но при первом посещении форма входа отправлялась по HTTP. Рассматривались два варианта: оставить только перенаправление, что не защищало первый запрос, или включить HSTS с распространением на поддомены после проверки их HTTPS-совместимости.
Был выбран второй вариант, а для дополнительной защиты первого посещения домен подготовили к предварительному включению в список HSTS. Перед этим проверили все поддомены, сертификаты, автоматическое продление и отсутствие сервисов, доступных только по HTTP.
В результате повторные HTTP-обращения перестали уходить в сеть как HTTP-запросы. Риск первой атаки для обычных пользователей снизился за счёт предварительного включения, а проверка поддоменов предотвратила отказ вспомогательных сервисов.
Перенаправление выполняется сервером после получения HTTP-запроса. HSTS применяется браузером до отправки запроса, поэтому при уже сохранённой политике исходное HTTP-обращение не покидает клиент. Однако при самом первом визите без предварительного включения HSTS браузер ещё не знает о политике, поэтому одно перенаправление не устраняет начальный риск.
Нет. Нужно проверить, что заголовок получен по HTTPS, имеет подходящий срок действия и реально влияет на последующие обращения браузера. Следует также проверить поддомены, варианты портов и поведение в чистом профиле, потому что уже сохранённая политика может скрыть ошибку первоначальной настройки.
Эти настройки расширяют область действия правила. Если хотя бы один обязательный поддомен не поддерживает HTTPS или имеет неисправный сертификат, пользователи могут потерять доступ к нему. Предварительное включение особенно трудно быстро отменить: обновление списков браузеров занимает время, поэтому перед ним необходим аудит всех поддоменов и готовность полностью обслуживать домен по HTTPS.