Session Fixation

What Is Session Fixation?

Fixation and hijacking differ on when the attacker gets the session id. A hijacker steals it after you authenticate. Fixation plants a known value before, and lets your own login upgrade it. You'll pin a live anonymous id into a link, watch the victim sign in, and load her dashboard with that same string. The handler reads const sid = req.cookies.sid || crypto.randomUUID() . The fix mints a new id unconditionally on every authentication and privilege transition, which is why entropy and HttpOnly do not close this one.

What You'll Learn in Session Fixation

• Distinguish session fixation from session hijacking by when the id is in the attacker's possession (before login vs after)
• Recognize that any cookie-write primitive (subdomain XSS, MITM, response-splitting) is enough to enable fixation
• Apply unconditional session-id rotation on every successful authentication (and on every privilege transition)
• Pair the rotation with explicit deletion of the pre-login session id so the old binding cannot continue server-side
• Audit every authentication-state transition for the same rotation hook (login, post-MFA, role elevation, password change)

Session Fixation — Training Steps

1. Bob's plan

   Bob cannot steal Alice's password, and he does not need to. His plan is to hand her a session id he already knows, then let her log in on top of it, so the session she ends up authenticated on is one he controls. First he needs a session id to plant. He opens the Sundermark Logistics portal himself, and this legacy portal hands his browser an anonymous session id and echoes it straight into the address bar as a ?sid value, exactly as it would any visitor.

2. A valid session id to plant

   Bob opens the browser's cookie inspector. The portal has already handed him a session id, before he has logged in or done anything. It is anonymous, but it is a real value the server issued and will honour. This is the exact id he will plant on Alice.

3. Weaponize it into a link

   Bob does not have to build anything. The session id the server gave him is already pinned to the address as ?sid=SID-9F3A2B1C7D , and the portal has a legacy quirk: it copies that sid straight out of the URL into the visitor's cookie. So this exact link is the trap. Anyone Bob sends it to has his session id planted in their cookie the moment they open it.

4. Send the trap to Alice

   Bob targets Alice, an employee whose portal account he wants. He opens his email and writes her a message dressed up as a routine IT access notice, carrying the same session-id link in the body. All he needs is for her to open it and sign in.

5. A routine access notice

   Off the clock, Alice gets an email that reads like IT housekeeping: confirm your portal access before end of day. The link points to the real portal, so nothing jumps out.

6. One click hands over the cookie

   Alice clicks the link. It opens the real portal sign-in page, exactly as expected. What she cannot see: the portal just copied the sid from the link into her cookie jar. Her browser now holds Bob's session id.

7. Alice signs in

   Alice signs in with her Sundermark credentials, just like the notice asked. The portal welcomes her and drops her on her dashboard. Nothing looks wrong. Her account, her details, her session.

8. The id that should have changed

   Here is the flaw, made visible. A safe login mints a brand-new session id at the moment you authenticate, so the id you carried in is thrown away. Alice's id did not change. The cookie on her authenticated dashboard is byte-for-byte the value that rode in on the emailed link, the value Bob planted.

9. Bob refreshes into her account

   Bob still has the sign-in page open in his browser, the one he loaded with his planted session id. A minute after Alice signs in, he simply refreshes it. His planted id is now bound to her authenticated session, so the portal treats his request as hers and bounces him straight to her dashboard. No password, no theft, no malware.

10. Name what happened

    Before Alice switches from victim to engineer, be precise about the attack.