Session Fixation

Session Fixation is an attack technique that forces a user’s session identifier to a known value controlled by the attacker. The vulnerability arises when a web application does not regenerate a new session identifier upon successful authentication, allowing the attacker to reuse a previously established session ID. Once the victim logs in with the fixated session, the attacker can hijack the authenticated session to impersonate the victim and gain full access to their account without needing their credentials.

A successful Session Fixation attack allows an attacker to completely bypass authentication and take over a victim’s session, potentially leading to unauthorized access to sensitive data, privilege escalation, or full account compromise. Exploitation typically involves the attacker obtaining or generating a valid session ID and then delivering it to the victim via a crafted URL parameter, a hidden form field, or by injecting a Set-Cookie header through techniques such as cross-site scripting (XSS), CRLF injection, or man-in-the-middle interception. The severity of impact scales with the privileges of the compromised account; hijacking an administrator session, for example, could expose the entire application and its data.

Always regenerate the session identifier immediately after a user authenticates successfully. The server must invalidate the old session and issue a completely new session ID upon login, ensuring that any pre-authentication token becomes unusable.

Bind session identifiers to client-specific attributes such as the IP address or SSL client certificate to make stolen tokens harder to reuse from a different context.

Use cookies with the HttpOnly and Secure flags as the sole transport mechanism for session tokens. Never pass session identifiers in URL query parameters or GET variables, as these are easily exposed in browser history, referrer headers, and server logs.

Enforce absolute session timeouts and idle timeouts to limit the window of opportunity for an attacker. After a period of inactivity (for example, 10 to 15 minutes), the session should be automatically invalidated on the server side.

Implement a logout mechanism that fully destroys the session both on the server and on the client, removing all associated cookies and stored state.

Switch from URL-based session management to cookie-based or form-based (POST) session handling, as URL-based tokens are significantly easier to exploit through social engineering and link sharing.