Home / Knowledge hub / Session fixation
Knowledge hub
Session fixation
An attacker sets your session id before login, then waits for it to work.
What it means
Session fixation attacks the moment you log in. The attacker arranges for your browser to carry a session identifier they already know, often through a link that contains one, and then waits.
You sign in, the application keeps that same identifier, and the attacker's copy quietly becomes a logged in session as you.
Why it matters
The result is an account takeover that never touched your password. Nobody guessed anything and nobody stole anything from your machine, so no failed login raises an alert and nothing in your own behaviour looks odd.
It also sits among the cheapest classes to get right, which makes it an unhappy thing to read in a report. One decision, made once, at the point of login, closes it. The bug travels with other session problems too. An application that reuses an identifier through login often reuses it through logout. Buyers read it as a sign of something wider. A team that missed this usually built session handling by hand, so reviewers start looking for the rest.
How it shows up
The test takes a minute. Note the session identifier before you sign in, sign in, then look again. If the string matches, the application is vulnerable. MITRE catalogues it as CWE-384.
Issue a brand new session the moment authentication succeeds, and discard the old one. Most frameworks expose a single call for this, so the bug turns up where somebody built login by hand. Check every place identity changes, not only login. Switching accounts, elevating to an admin mode and impersonating a customer for support each deserve a fresh session. Cookies set over plain HTTP deserve a look too, because an attacker can plant one there and watch it survive the move to HTTPS.
Questions people ask
Session fixation, answered
What is the difference between session fixation and session hijacking?
Timing. In fixation the attacker plants an identifier before you log in and waits for it to become valid.
In session hijacking they steal one that is already valid. The end state is the same.
Is session fixation still a real problem?
It is rare in framework managed login and common in login somebody wrote by hand.
OWASP and MITRE both still track it, which tells you it still turns up in real applications.
Does regenerating the session id fix it completely?
Yes, provided you also discard the old identifier and do it everywhere identity changes.
Issuing a new identifier while the old one keeps working fixes nothing at all.
Does my framework already protect me?
Most mainstream frameworks regenerate the session on login, and nearly all expose one call to do it.
Check rather than assume, especially if somebody customised the login flow or wrote a second one for admins.
How do I test for session fixation myself?
Read the session cookie before you sign in, sign in, then read it again. The same value means vulnerable.
It takes a minute and needs nothing beyond your browser's developer tools.
Sources
Where this comes from
Related
Terms that sit next to this one
Session hijacking
Stealing the token that tells your application a browser is logged in.
Authentication
Proving you are who you say you are. It answers one question only.
Token
A string that stands in for an identity or a permission.
Account takeover
An attacker ends up signed in as one of your real users.
Does your session id survive login?
Authentication counts as one of the ten vulnerability classes Cyberlop tests, and a finding arrives with the before and after requests attached. Start with one application for $199.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.