How Fixation Works
In a session fixation attack, the attacker first obtains or sets a known session identifier, then tricks a victim into authenticating under that same identifier. If the server keeps the pre login session after authentication, the attacker, who already knows the identifier, is now logged in as the victim.
The root cause is reusing the same session identifier across the login boundary.
The Defense
The fix is simple and reliable:
- Regenerate the session identifier on login, discarding the old one and issuing a fresh value the attacker cannot know.
- Also regenerate on any privilege change, such as elevating to an admin role.
- Never accept a session identifier supplied through the URL, since that makes fixation trivial.
- Bind cookies with HttpOnly, Secure, and a strict SameSite setting to reduce related theft.
Because the new identifier is created after authentication and tied to the now authenticated user, the attacker holds a stale, useless value.
Key idea
Session fixation works when a pre login session identifier survives authentication, so the defense is to regenerate the session identifier at login and on privilege changes, leaving any attacker known value stale.