Summary
A session fixation vulnerability allows an attacker to establish or predict a session identifier before a victim authenticates. Because the application does not issue a new session ID after authentication, the attacker may reuse that identifier to access the victim's authenticated session.
Affected context
The vulnerability occurs in authentication flows that accept user-supplied session identifiers and retain them after a user successfully signs in. It becomes risky when an attacker can cause a victim to use a known session ID and can later present that same identifier to the application.
Exploit preconditions
- Attack surface: Web session management and authentication endpoints
- Required access: Ability to influence or establish a session identifier used by the victim
- Trigger point: Successful authentication without session ID regeneration
- Why exploitation is possible: The pre-authentication session remains associated with the authenticated account, allowing reuse by someone who knows the identifier
Why this happens
The application treats a client-provided or pre-authentication session identifier as trustworthy and fails to rotate it when authentication changes the session's privilege state. This behavior maps to CWE-384: Session Fixation, where an attacker can cause a known session identifier to remain valid after the victim authenticates.
Potential impact
- An attacker may take over a victim's authenticated session
- Unauthorized access to account data or functions may occur
- Actions could be performed under the victim's identity
- Sensitive information may be exposed or modified
- Account or application integrity can be affected
General mitigation guidance
Mitigation typically focuses on making session identifiers server-generated, unpredictable, and bound to the correct authentication state.
Common defensive patterns include:
- Regenerating the session ID immediately after successful authentication and privilege changes
- Rejecting or replacing user-supplied session identifiers rather than adopting them
- Invalidating the pre-authentication session when creating an authenticated session
- Applying secure cookie attributes, appropriate expiration, and server-side session invalidation
- Limiting session privileges before authentication and applying least privilege after authentication
- Reducing reliance on client-controlled session state and enforcing centralized session-management policies
How teams detect issues like this
Organizations commonly detect session fixation risks through:
- Static analysis checks for authentication code that preserves session IDs across login transitions
- Code review of session creation, login, privilege elevation, and logout paths
- Dynamic tests that compare session identifiers before and after authentication
- Policy enforcement requiring session rotation whenever authentication or authorization state changes
- Monitoring for concurrent or unusual reuse of the same session identifier across clients or locations
Automated security testing and code review tools may help identify missing session rotation and unsafe acceptance of client-controlled identifiers.
