Session Fixation

Reports cluster around:

• session ID not rotated on login (Acronis cookie reuse)
• session ID not rotated on password entry for protected guest links (Nextcloud Spreed CVE-2021-32676)
• Apache Airflow CVE-2023-40273 - password reset doesn't invalidate session
• cookie injection from non-secure HTTP context that persists into HTTPS (curl)
• session not invalidated after logout. Substantially overlaps with Insufficient Session Expiration synthesis.

• Authenticated web sessions across login / password-reset flows
• Guest-link-protected resources
• Nextcloud Spreed talk rooms
• Apache Airflow web UI

• Pre-set session cookie on victim's browser via response splitting / sibling subdomain
• Wait for victim to log in and inherit attacker's session ID
• Password change doesn't invalidate other devices

• Set-Cookie: sessionid=ATTACKER_VALUE (via XSS or sibling domain)
• Cookie injection via http://target/ -> https://target/ persistence

Replaying a session after logout and after a password change, checks shared with the insufficient-session-expiration category, both apply here too. The most direct test for fixation itself: capture the session cookie before logging in, complete the login, and check whether the session ID actually changed, since a session that persists unchanged across authentication is the core of the bug.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

Some apps intentionally re-use session IDs as 'remember me'; flag when no fresh token is issued OR when both old and new cookies remain valid post-login.

Manual Testing Methodology

Here is a systematic approach to identifying Session Fixation vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Session Fixation specifically, capture a valid pre-authentication session identifier, force it onto a victim session (via a link or shared cookie path), then authenticate as the victim and check whether the pre-set identifier remains valid post-login; separately, attempt to tamper with cookie/session-token content and see if the modified value is still accepted.

Compare the response against your baseline, looking specifically for a session identifier that survives login unchanged (fixation confirmed), or a tampered cookie/token value that the server still treats as valid — either indicates the session isn't properly regenerated or integrity-checked.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Session Fixation, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Session-management flaws let an attacker take over an authenticated session without ever obtaining the victim's actual credentials. Session fixation lets an attacker set a known session identifier on a victim before login and then use that same identifier once the victim authenticates, inheriting their session outright. A session cookie that isn't integrity-protected can be tampered with directly, letting an attacker forge or elevate a session's claimed identity or privileges.

Both failure modes are attractive to attackers precisely because they skip the credential-theft step entirely — no phishing, no password guessing, just a manipulated identifier or cookie value.

The practical result in either case is full account takeover for the affected session, with the same downstream impact as if the attacker had stolen the password directly.

Prevention and Secure Coding

Preventing Session Fixation takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Regenerate the session ID on authentication. Issue a brand-new session identifier immediately after login, invalidating whatever pre-authentication session existed — this defeats fixation regardless of how the attacker obtained the original ID.

Sign or store sessions server-side. Use a signed session token (verified with a server-held secret) or a server-side session store, so a client can't forge or modify session content undetected.

Cookie security flags. Set HttpOnly, Secure, and an appropriate SameSite value on session cookies as a baseline, regardless of the other controls in place.

Expire sessions actively. Enforce both inactivity timeout and explicit invalidation on logout server-side — a client-side "logged out" state that leaves the server-side session valid doesn't actually end the session.