Session
fixation.

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

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

HTTP-запросы сами по себе не помнят предыдущие действия. Поэтому после создания сессии сервер выдаёт браузеру идентификатор, обычно через cookie. В следующих запросах браузер возвращает этот ID, а сервер находит связанные с ним данные: например, сведения о входе и права пользователя.

Идентификатор не равен паролю и обычно выглядит как случайная строка. Однако действующий ID может служить пропуском в сессию. Поэтому его нельзя раскрывать, предсказуемо генерировать или бесконтрольно сохранять при изменении прав. На следующем листе сравним два варианта входа.

Посмотрите на верхнюю строку схемы: до входа у браузера был ID A, и после входа остался тот же ID A. Если этот идентификатор ранее узнал атакующий, сервер теперь воспринимает его как ключ к уже авторизованной сессии. Так анонимный контекст получает права аккаунта.

Нижняя строка показывает безопасный переход: после проверки учётных данных сервер создаёт ID B, связывает с ним аккаунт и прекращает действие ID A. Именно этот переход разрывает цепочку. Даже если прежний ID известен постороннему, он больше не даёт доступ.

Сценарий на листе намеренно упрощён и нужен для понимания механизма. Сначала атакующий получает идентификатор анонимной сессии. Затем добивается того, чтобы браузер жертвы использовал этот же ID. Конкретные пути навязывания зависят от уязвимостей и настроек приложения.

После этого жертва самостоятельно входит в свой аккаунт. Ошибка возникает, если сервер оставляет тот же ID действительным, только теперь уже с правами пользователя. Атакующий предъявляет известный ему идентификатор и попадает в чужую сессию. Защиту нужно поставить на переходе от анонимного состояния к авторизованному.

Фиксацию сессии часто путают с перехватом или кражей уже активной сессии. Разница не в результате — в обоих случаях атакующий может получить доступ, — а в последовательности событий. При fixation он знает ID до того, как жертва войдёт. При hijacking узнаёт идентификатор уже после входа.

Эта разница важна для выбора меры защиты. Ротация ID при входе прежде всего ломает сценарий фиксации. Защита от утечки действующего ID требует и других мер: защищённого соединения, корректных cookie-настроек и устранения уязвимостей, через которые данные могут раскрыться.

Центральное действие выполняет сервер после успешной проверки учётных данных: создаёт новый криптографически случайный ID, привязывает к нему авторизованную сессию и делает прежний ID недействительным. Недостаточно просто отправить новую cookie, если старый токен остаётся активным на сервере.

Такую смену проводят не только при первоначальном входе, но и при повышении привилегий: например, когда пользователь открывает административную область или подтверждает чувствительное действие. Анонимный идентификатор не должен автоматически наследовать новые права. Это главный пункт рекомендаций OWASP по предотвращению session fixation.

Атрибут Secure ограничивает передачу cookie защищённым соединением. HttpOnly запрещает доступ к ней через JavaScript и снижает риск раскрытия ID при XSS. SameSite помогает ограничить отправку cookie в межсайтовых запросах. Domain и Path задают область действия; лишнее расширение Domain позволяет большему числу поддоменов влиять на cookie.

Префикс __Host- накладывает дополнительные ограничения: cookie должна быть Secure, иметь Path=/ и не содержать Domain. Он полезен там, где подходит такая область действия. Но ни один из этих атрибутов не исправляет ситуацию, когда сервер оставляет известный ID после входа. Ротация остаётся обязательной.

Идентификатор должен быть случайным и создаваться на сервере. Если клиент отправил произвольную строку, сервер не должен считать её готовой сессией и тем более связывать с аккаунтом. При каждом запросе сервер проверяет, что ID существует, действует и соответствует нужному состоянию.

При выходе из аккаунта старый ID отзывают. При смене прав и повторной аутентификации ID обновляют. Дополнительно полезны таймаут бездействия и общий срок жизни сессии. Эти меры сокращают время, в течение которого чужой или забытый идентификатор может оставаться полезным.

Проверяйте собственное приложение или тестовую среду, на работу с которой у вас есть разрешение. Откройте сайт без входа и зафиксируйте ID анонимной сессии. Затем войдите в тестовый аккаунт и посмотрите новый ID. Он должен отличаться от прежнего.

Второй шаг столь же важен: старый ID должен перестать открывать защищённые данные. Если ID сменился в браузере, но прежний ещё работает на сервере, защита неполная. Зафиксируйте ожидаемый результат в автоматическом тесте, чтобы ошибка не вернулась после изменения логики авторизации.

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

Попросите аудиторию назвать три типичные ошибки: не менять ID после входа, считать Secure или HttpOnly полной заменой ротации и забывать отзывать сессию при выходе или смене прав. Для самостоятельного чтения рекомендуйте OWASP Session Management Cheat Sheet и документацию MDN по cookie.