Краткий ответ

Для этого сессионный cookie должен иметь атрибут HttpOnly. Браузер продолжает отправлять такой cookie в подходящих HTTP-запросах, но не предоставляет его значение скриптам через механизм доступа к cookie. Тестировщик должен проверить наличие атрибута в ответе сервера и убедиться, что клиентский JavaScript не может прочитать значение сессии.

Исторический контекст

HttpOnly появился как защитная мера против кражи сессионных идентификаторов через уязвимости XSS. Исходная проблема заключалась в том, что внедрённый скрипт мог прочитать cookie и передать его злоумышленнику, после чего тот получал возможность использовать сессию жертвы.

Этот атрибут не устраняет саму XSS-уязвимость. Он ограничивает один из наиболее опасных последствий — прямое извлечение значения cookie из сценария браузера.

Постановка проблемы

Если сессионный cookie доступен JavaScript, успешная XSS-атака может привести к краже сессии. Злоумышленник сможет использовать скопированный идентификатор вне браузера жертвы, пока сервер считает соответствующую сессию действительной.

Наличие HttpOnly не означает, что XSS становится безопасной. Внедрённый скрипт обычно всё ещё может выполнять действия от имени пользователя через браузер: отправлять запросы, читать доступные ответы и изменять данные, если другие механизмы защиты этого не запрещают.

Подробное решение

При установке сессионного cookie сервер должен указывать атрибут HttpOnly. Браузер тогда исключает этот cookie из интерфейса, предназначенного для чтения cookie сценариями, но может автоматически добавлять его к запросам, соответствующим области действия cookie.

Проверка включает несколько шагов:

изучить заголовок установки cookie и убедиться, что у сессионного cookie присутствует HttpOnly;
проверить в браузере, что скрипт не получает значение этого cookie через клиентский механизм чтения cookie;
убедиться, что тестируется именно сессионный идентификатор, а не второстепенный cookie;
проверить, не хранится ли тот же идентификатор параллельно в доступном JavaScript хранилище или в DOM.

HttpOnly не защищает cookie от перехвата при передаче по незащищённому соединению. Для этого нужен Secure, а правильная область отправки cookie дополнительно задаётся атрибутами Domain, Path и SameSite. Эти атрибуты решают разные задачи и не заменяют друг друга.

Даже при установленном HttpOnly XSS может использовать автоматически прикрепляемую браузером сессию для выполнения разрешённых пользователю операций. Поэтому результат теста следует формулировать точно: атрибут снижает риск кражи cookie скриптом, но не является полноценной защитой от XSS или подделки запросов.

Ситуация из практики

В приложении найден HTML-инъекционный дефект в разделе профиля. Сессионный cookie не имел HttpOnly, поэтому внедрённый сценарий мог прочитать его значение и передать на внешний сервер.

Рассматривались два варианта. Полное устранение XSS было обязательным, но само по себе не заменяло защиту cookie: ошибка могла появиться снова. Добавление HttpOnly быстро закрывало прямое чтение сессии, однако не препятствовало выполнению действий через украденную или автоматически используемую браузером сессию.

Выбрали оба направления: исправили контекстное экранирование вывода и установили HttpOnly для всех сессионных cookie. Дополнительно проверили Secure, срок жизни сессий и серверную авторизацию операций. В результате прямое извлечение cookie через сценарий стало невозможным, а первопричина XSS и смежные риски были устранены отдельно.

Что кандидаты часто упускают

1. Достаточно ли HttpOnly, чтобы XSS не могла изменить данные пользователя?

Нет. Скрипт не может прочитать значение защищённого cookie, но браузер может автоматически отправлять его с запросами к приложению. Если запрос не требует дополнительной защиты и операция разрешена текущему пользователю, внедрённый сценарий способен инициировать такую операцию от его имени.

2. Можно ли считать сессионный cookie защищённым, если у него есть HttpOnly, но нет Secure?

Нет. HttpOnly ограничивает доступ сценариев, а Secure требует отправлять cookie только по защищённому соединению. При отсутствии Secure возможна утечка cookie через HTTP-соединение или ошибочно доступный незащищённый маршрут, поэтому оба атрибута проверяют независимо.

3. Что делать, если приложение использует токен из localStorage вместо cookie?

HttpOnly не защищает токены, хранящиеся в localStorage, поскольку JavaScript по своей природе может читать это хранилище. Тестировщик должен отдельно определить место хранения и проверить последствия XSS: возможность извлечения токена, срок его действия, отзыв и серверные ограничения. Простое наличие HttpOnly у другого cookie в таком случае не доказывает защиту сессии.