Как смена идентификатора сессии при повышении привилегий предотвращает фиксацию сессии?
При успешной аутентификации сервер должен заменить предаутентификационный идентификатор сессии на новый, случайный и связать его с уже аутентифицированным пользователем. Это предотвращает фиксацию сессии: злоумышленник не сможет заранее навязать жертве известный идентификатор, а затем использовать его после входа жертвы.
Ранние веб-приложения часто сохраняли один и тот же идентификатор сессии до и после входа пользователя. Такой подход был удобен для реализации, но создавал связь между анонимной и аутентифицированной фазами работы.
Проблема стала особенно заметной в системах, где идентификатор можно было заранее установить через ссылку, параметр или другой управляемый канал. Защитным решением стала регенерация идентификатора сессии при изменении уровня доверия.
Атакующий пытается заставить пользователя начать работу с заранее известным идентификатором сессии. Если после ввода пароля сервер сохраняет этот же идентификатор и только добавляет к сессии сведения о пользователе, атакующий уже знает действующий идентификатор привилегированной сессии.
В результате злоумышленник может получить доступ без кражи пароля или перехвата нового cookie. Наличие TLS не устраняет эту проблему: шифрование защищает передачу, но не делает заранее известный идентификатор непредсказуемым.
При успешной аутентификации сервер должен выполнить ротацию сессии: создать новый криптографически случайный идентификатор, перенести в новую серверную сессию только безопасное состояние и немедленно инвалидировать старую. Cookie с новым идентификатором передаётся клиенту с атрибутами Secure, HttpOnly и подходящим SameSite.
Такая же смена должна происходить при других существенных изменениях доверия, например при переходе к административной роли или восстановлении доступа. Важно, чтобы старая сессия действительно перестала приниматься сервером, а не просто получила признак устаревшей.
Серверная сессия должна хранить идентификатор пользователя, состояние аутентификации и необходимые ограничения, но не пароль и не избыточные секреты. Идентификатор должен быть непредсказуемым, иметь достаточную длину и генерироваться криптографически стойким генератором случайных чисел.
Ротация идентификатора не защищает от всех угонов сессии. Если новый cookie уже украден через вредоносное расширение, уязвимость приложения или компрометацию устройства, одной ротации недостаточно; нужны защита от XSS, корректные атрибуты cookie, ограничение времени жизни, отзыв сессий и повторная аутентификация для критичных действий.
Ротация может создать проблемы с несколькими вкладками или параллельными запросами. Поэтому серверу нужно корректно обрабатывать короткое окно конкурирующих запросов, не возвращая при этом старый идентификатор в ответе и не оставляя старую сессию действительной дольше необходимого.
В интернет-магазине анонимная корзина создавалась сразу при первом посещении и связывалась с cookie сессии. После входа приложение добавляло к той же сессии идентификатор пользователя. Атакующий мог заранее передать жертве ссылку, инициирующую известную сессию, а после входа использовать её для обращения к аккаунту.
Рассматривались два варианта. Полное удаление анонимной корзины после входа было безопаснее, но ухудшало пользовательский опыт. Сохранение прежнего идентификатора было удобнее, однако оставляло уязвимость. Выбрали перенос корзины в новую сессию с одновременной инвалидизацией старой.
В результате пользователь сохранил содержимое корзины, но предаутентификационный идентификатор больше не давал доступа к аккаунту. Дополнительно для изменения платёжных данных потребовали повторную аутентификацию.
1. Достаточно ли просто добавить признак аутентификации к существующей сессии?
Нет. Если идентификатор не изменился, атакующий, знающий его до входа, продолжит использовать ту же сессию после повышения привилегий. Нужна именно замена идентификатора с инвалидизацией старого состояния.
2. Нужно ли ротировать сессию при каждом запросе?
Обычно нет. Постоянная ротация усложняет параллельные запросы, работу нескольких вкладок и восстановление состояния, не давая сопоставимой пользы. Ключевые моменты — аутентификация, смена привилегий и другие переходы через границу доверия.
3. Что произойдёт, если старая сессия формально заменена, но сервер ещё принимает её в течение некоторого времени?
Защита от фиксации станет неполной: злоумышленник сможет использовать старый идентификатор в этом окне. Допустимое краткое перекрытие иногда применяют для обработки гонок, но старую сессию нельзя принимать как аутентифицированную; безопаснее связать её с одноразовым переходом или сразу отклонять её запросы.