Session Fixation

ATT&CKT1539

Session Fixation abuses an application that does not renew the session identifier on authentication. If the attacker manages to fix a known identifier in the victim's browser beforehand and the application keeps it after login, that same identifier ends up authenticated and the attacker, who already knows it, inherits the session. The difference from cookie theft is subtle but key: here the id is not stolen afterwards, it is imposed beforehand.

The typical vector: the application accepts a sessionid arriving via URL or via a cookie the attacker can plant (through open redirect, a subdomain or an XSS), and does not rotate it on login. The attacker fixes the value, lures the victim into authenticating, and reuses the now-validated id.

# 1) the attacker forces a known id on the victim
https://app.example.com/login?sessionid=ATTACKER_FIXED
# 2) the victim logs in; the app does NOT rotate the id -> ATTACKER_FIXED is authenticated
# 3) the attacker uses that same id and enters as the victim
Cookie: sessionid=ATTACKER_FIXED

A related variant (session puzzling) is when a secondary flow grants a valid session without authenticating: for instance, a "forgot password" that returns a usable session token in its response, allowing entry to private areas with no credentials. You check it by observing in Burp whether that flow's response carries a Set-Cookie/JWT that already works for authenticated browsing.

Requirements. The application must (1) accept a session identifier the attacker can influence (via URL, a plantable cookie or a flow that issues it) and (2) not regenerate it after a privilege change (login, elevation). If the server issues a new, random id on authentication, the fixed id is voided and the attack fails.

How to detect it. In the log, the signature is the same session identifier used before and after login (it does not change on authentication) and, often, the same id appearing from two different IP addresses (attacker and victim). A recovery flow that issues valid session tokens with no prior authentication is another direct sign in response analysis.

Defence. Regenerate the session identifier on every privilege change (after login and after elevation), do not accept a session id via URL, mark cookies HttpOnly, Secure and SameSite, and do not issue valid sessions in flows that do not authenticate. It relates to token handling in JWT and to the session theft of XSS.

ToolsBeEF