Session fixation → account takeover

Summary

Session fixation is an attack where the attacker fixes a user's session token to a value they already know, before the victim logs in. If the application does not issue a fresh token when the user authenticates, that pre-set token becomes a fully authenticated session. Because the attacker knows the token, they can then use it to access the victim's account. On app.example.co.za the token issued before login was not replaced at authentication, so a token planted in the victim's browser led to full account takeover without ever knowing the victim's password.

How the attack works

1. The attacker obtains a valid session token from the application. Visiting the site normally hands one out.
2. The attacker gets that token set as the victim's session token, so it is "fixed" before login. This can be done through a crafted link, a token the app accepts in the URL, or a script that writes the session cookie.
3. The victim logs in. The application does not regenerate the session token on authentication, so the attacker-known token is now authenticated.
4. The attacker replays the same token from their own machine and is inside the victim's account.

Why it was possible

The application accepted a pre-existing session token and, critically, did not regenerate the session identifier at login or on any change of privilege. This is the defining condition for session fixation (CWE-384). It differs from session hijacking: in hijacking the attacker steals a token the victim already holds, whereas in fixation the attacker sets the token first and lets the victim authenticate it.

Impact

Any account can be taken over wherever the attacker has a way to seed a token in the victim's browser, for example a link on the same domain or a script on a subdomain. During the engagement the operator authenticated as a real test user and reached that user's account settings from a separate host.

Fix

• Generate a brand-new session token every time a user logs in, and again on any privilege change. Never reuse a token that existed before authentication.
• Never accept session tokens from the URL or query string. Transmit them only in cookies, or in hidden fields submitted by POST.
• Set HttpOnly, Secure and SameSite on the session cookie, bind it to server-side session state, and invalidate it on logout and expiry.

Verification

Reproduced by hand and signed by OSCP-certified operator. A fix re-test is included in the engagement.

Reference: PortSwigger Web Security Academy — session management and session fixation.