Веб-сервис принимает запросы по HTTPS, но сессионный cookie не помечен атрибутом Secure. Какую проверку должен провести тестировщик?
Тестировщик должен проверить, отправляется ли сессионный cookie при обращении к тому же сервису по обычному HTTP. Если cookie передаётся без атрибута Secure, браузер может включить его в HTTP-запрос, где значение сессии можно перехватить или раскрыть.
Cookies создавались как механизм автоматического хранения состояния между HTTP-запросами. Поскольку HTTP и HTTPS используют одну модель адресации, без специального ограничения браузер может отправлять cookie по незащищённому каналу.
Атрибут Secure появился для привязки передачи cookie к защищённому соединению. Он решает только задачу канала передачи: шифрование обеспечивает TLS, а не сам атрибут.
Нужно проверить фактическое поведение клиента, а не только наличие HTTPS в интерфейсе приложения. Следует проанализировать заголовок Set-Cookie, затем выполнить обращение по HTTP и убедиться, что сессионное значение отсутствует в заголовке Cookie.
Если атрибут не задан, злоумышленник, способный наблюдать или изменять трафик в незащищённой сети, может получить идентификатор сессии. После этого он сможет использовать его для доступа к учётной записи до истечения сессии или её принудительного отзыва.
В тесте проверяют следующие условия:
Важно проверять именно сетевые запросы, а не только адресную строку браузера. Наличие автоматического перенаправления на HTTPS не исправляет отсутствие Secure: cookie может быть отправлен уже в первом HTTP-запросе до перенаправления.
HSTS уменьшает риск повторного обращения браузера по HTTP, но не заменяет Secure. HSTS зависит от политики конкретного клиента и не защищает все возможные HTTP-клиенты, поэтому безопасная конфигурация должна использовать оба механизма там, где они применимы.
Атрибут Secure не защищает cookie от чтения вредоносным скриптом в браузере. Для ограничения такого сценария обычно отдельно рассматривают HttpOnly, а для защиты от межсайтовой отправки — SameSite. Эти атрибуты решают другие задачи и не являются заменой друг другу.
В тестовой среде приложение всегда перенаправляло HTTP на HTTPS, поэтому команда считала проблему отсутствующей. Проверка сетевых запросов показала, что первый HTTP-запрос содержал сессионный cookie, а уже затем выполнялся редирект.
Рассматривались три варианта. Только редирект был прост в реализации, но не предотвращал утечку первого запроса. Только HSTS защищал поддерживающие его браузеры после применения политики, однако не покрывал все клиенты и первоначальный период до её получения. Установка Secure на cookie блокировала его передачу по HTTP независимо от наличия редиректа.
Выбранное решение включало Secure для всех сессионных cookies, принудительный переход на HTTPS и настройку HSTS после проверки готовности всех поддоменов. Повторный тест подтвердил, что HTTP-запрос не содержал сессионного значения, а HTTPS-сессия продолжала работать корректно.
Нет. Наличие атрибута в ответе важно, но итоговая проверка должна включать фактическую отправку cookie. Нужно убедиться, что браузер не прикладывает сессионное значение к HTTP-запросу, а также проверить уже существующие cookies после обновления конфигурации. Старый cookie без Secure может продолжать существовать до удаления или истечения срока действия.
Нет. Secure ограничивает передачу cookie защищённым соединением, но не запрещает скрипту выполнять действия от имени пользователя. Для запрета доступа JavaScript к cookie используют HttpOnly, однако и он не устраняет возможность действия через уязвимый скрипт. Поэтому проверка должна рассматривать защиту канала и защиту браузерного контекста отдельно.
Это снижает практический риск, но не отменяет корректную настройку cookie. HTTP может появиться из-за балансировщика, отдельного поддомена, ошибочной маршрутизации или другого клиента, который не следует политике браузера. Атрибут Secure задаёт дополнительное ограничение на стороне клиента и поэтому остаётся обязательным свойством сессионного cookie.