Session Fixation

What Is Session Fixation?

Session fixation differs from hijacking on a single axis: the attacker plants the session id BEFORE the victim logs in, instead of stealing it after. The hostile primitive is any way to get a known value into a cookie on the application's domain (a link carrying a sid the app copies into the cookie, subdomain XSS, response-splitting, MITM on a public network). Once the planted id is in the victim's jar, the victim's normal login is enough to upgrade that id to an authenticated session, and the attacker still holds the same string. This exercise puts you on both sides. As Bob, you pull a live anonymous session id from Sundermark Logistics' employee portal, pin it into a link to the real site, and let the victim's own login upgrade it, then load her dashboard with the id you planted. As Alice, on the receiving end of a 'two clients sharing one session id immediately post-login' anomaly, you open the login handler, see const sid = req.cookies.sid || crypto.randomUUID() , and ship the fix: destroy the incoming session and mint a fresh crypto.randomUUID() unconditionally, discarding whatever id arrived on the request. The exercise closes with quiz questions on what distinguishes fixation from hijacking, why rotation is the single control that closes the window, and why entropy and HttpOnly do not.

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.