Перейти к содержимому
>_ITDITDПлатформа веб-безопасности

Глоссарий

#фиксация сессии#уязвимость#web

Что такое фиксация сессии — заставить жертву войти с ID, который атакующий уже знает

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

Опубликовано 2026-06-11 Обновлено 2026-06-11 3 мин чтения

«Жертва входит с ID, который подготовил атакующий» — это и есть фиксация сессии. Вот как она работает и как её надёжно предотвратить (без шагов атаки).

Почему это работает

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

1) Атакующий заставляет жертву использовать известный ID сессии (через ссылку и т. п.)
↓ жертва входит с этим ID, всё ещё установленным
2) ID не регенерируется = тот же ID становится «аутентифицированным»
↓ атакующий знал этот ID всё это время
3) Доступ с тем же ID = выдача себя за жертву
Если ID не меняется при входе, ID, известный атакующему заранее, становится аутентифицированным как есть.

Это может сочетаться с CSRF или XSS, но суть самой фиксации — одна вещь: ID не был регенерирован при входе.

Защита: регенерируйте ID при входе

1

Регенерируйте ID сессии при успешном входе (самое важное)

В тот миг, когда аутентификация успешна, отбросьте старый ID и выдайте новый ID сессии (session regenerate/renew у большинства фреймворков). Любой заранее подброшенный ID немедленно становится недействительным. Регенерируйте и при эскалации привилегий (например, при получении прав администратора).
2

Не принимайте ID сессии через URL

Обрабатывайте ID сессии в cookie и игнорируйте ID, заданный в параметре URL. Закройте путь, которым атакующий заставляет жертву принять «зафиксированный» ID.
3

Укрепите флаги cookie

Выставьте сессионным cookie HttpOnly (JS не может читать), Secure (только HTTPS) и SameSite (ограничивает межсайтовую отправку). Это вместе ослабляет связанные пути перехвата.
4

Разумно завершайте сессии

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

Мнение этого сайта: не отключайте «регенерацию» во фреймворке

Фиксация сессии в основном закрывается одним ходом — регенерацией ID при входе — а не сложным самописным кодом. Ключ в том, чтобы случайно не отключить и не забыть вызвать механизм, который ваш фреймворк уже предоставляет. Опираться на безопасные значения по умолчанию проверенной реализации лучше, чем самому собирать управление сессиями. На этом сайте мы держимся правила «не пишите аутентификацию/работу с ключами сами; не отключайте безопасные значения по умолчанию». Как и с IDOR, аутентификация/авторизация должны обеспечиваться механизмом на каждом запросе.

Читать дальше

FAQ

QЧем фиксация отличается от перехвата сессии?
A

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

QКакая защита главная?
A

Регенерировать ID сессии в момент входа. У большинства фреймворков/библиотек сессий это есть (session regenerate/renew): при успешной аутентификации отбросить старый ID и выдать новый. Уже это делает недействительным любой ID, подброшенный атакующим заранее. Регенерируйте и при смене привилегий (например, при получении прав администратора).

QПочему опасно помещать ID сессии в URL?
A

ID в URL легко утекает через общие ссылки, заголовок Referer, логи и историю браузера — это способ для атакующего заставить жертву использовать «зафиксированный» ID. Обрабатывайте ID сессии в cookie, а не в параметрах URL, и не принимайте ID, заданный через URL.