Session Fixation and Remember-Me Cookie Forgery

A clean login is not the end of the authentication story. The session that login establishes, and any "remember me" cookie that outlives it, are credentials in their own right. If the server reuses a session id across login, or hands out a persistent cookie you can guess or forge, you take over the account without touching the login at all. This page covers both. Practice on a free live target.

Inspect what the app hands you

Start by logging in and decoding every cookie. Two questions drive everything:

• Does the session id change at login, or is the pre-auth id carried straight through?
• Is there a persistent cookie, and what is inside it when you decode it?

Those two answers point you at fixation and at cookie forgery respectively.

Session fixation

Session fixation abuses an app that does not issue a fresh session id when a user authenticates. The attack:

1. Obtain a valid pre-auth session id        (SESSIONID=KNOWN123)
2. Deliver it to the victim so their browser uses it:
     https://target.example/?SESSIONID=KNOWN123     (if the app accepts ids from the URL)
     or via an XSS / subdomain cookie write:  document.cookie="SESSIONID=KNOWN123"
3. Victim logs in. If the id is NOT rotated on login, KNOWN123 is now authenticated.
4. Attacker reuses KNOWN123  ->  logged in as the victim.

The vulnerability is entirely in step 3: a secure app issues a brand-new id at the moment of login, which instantly invalidates any id the attacker planted. The tell you are looking for is the session id staying the same before and after authentication.

Remember-me cookie forgery

A "remember me" cookie has to re-establish identity on its own, long after the session is gone, which makes it a durable, high-value target. Decode it first. Two failure modes:

Guessable encodings. The cookie is just the identity in a reversible format:

base64:   YWRtaW46MTcwMDAwMDAwMA==  ->  admin:1700000000   (username:timestamp)
hex:      61646d696e                ->  admin

If you can read it, you can rewrite it. Change admin to a victim and re-encode.

Weak or leaked signatures. The cookie is a value plus a keyed signature meant to stop tampering:

pattern:  <username>:<unix-ts>:<hmac(username+ts, SECRET)>
forge:    base64(username) + "." + hmac_sha256(base64(username), SECRET)

That only holds if SECRET is strong and private. If the secret is weak, reused, or leaked, you forge a valid cookie for any user. A weak HMAC secret can even be cracked offline from a captured cookie (illustrative, mode 1450 is HMAC-SHA256 with the guessed secret as the key):

# cookie_hmac.txt holds one line: <hex-digest>:<signed-message>  (the data the cookie signed)
hashcat -m 1450 cookie_hmac.txt rockyou.txt

Once you hold the secret, you mint a persistent cookie for the victim and replay it. Because persistence is designed to survive sessions, a forged one is a durable takeover, which is exactly why persistent state must never be trusted unless it is signed with a strong server secret and can be revoked.

Why client-held state is the common thread

Fixation and cookie forgery are two faces of one mistake: trusting state the client holds. A session id the client can set, or a persistent cookie the client can read or forge, is attacker input. The server has to own the trust anchor: rotate the session id at login so the client cannot pre-set it, and sign persistent state with a secret the client never sees.

Fixing it

• Rotate the session id at login and on every privilege change, so a planted id is useless.
• Never accept a session id from a URL or an untrusted cookie write. Set it server-side as HttpOnly and Secure.
• Sign persistent cookies with a strong, random server secret, make them revocable, and tie them to server-side state rather than trusting the cookie alone.
• Invalidate sessions and persistent tokens on logout and password change.

Full defensive detail is in securing authentication. Next, see the remaining edges in other mechanisms, or try a fixation on a free lab.