Session Fixation & Session Management
detect, understand, remediate
Session fixation allows attackers to set a user's session ID before authentication, gaining access to the authenticated session. Weak session management amplifies the risk.
No credit card required. Free plan available forever.
What is session fixation?
Session fixation is an attack that allows an adversary to hijack a valid user session by setting or forcing the victim's session identifier to a known value before the victim authenticates. Once the victim logs in, the attacker already possesses the session token and can impersonate the authenticated user without needing their credentials.
Unlike session hijacking, where an attacker steals an existing session after authentication, session fixation works by planting the session ID beforehand. This is possible when the application accepts session identifiers from URL parameters, hidden form fields, or cookies set by an attacker-controlled subdomain.
Session fixation is particularly dangerous because it can bypass even strong authentication mechanisms. If the application does not regenerate the session identifier upon successful login, the pre-set token remains valid and the attacker gains full access to the authenticated session.
How it works
Obtain a session ID
The attacker requests a session from the target application or crafts a known session identifier value.
Fix the victim's session
The attacker tricks the victim into using the known session ID via a crafted URL, cross-site cookie injection, or a phishing link.
Victim authenticates
The victim logs in using the fixated session. The server authenticates the user but keeps the same session identifier.
Attacker hijacks session
The attacker uses the pre-set session ID to access the application as the authenticated victim with full privileges.
Common causes
Session not regenerated after login
The application reuses the same session ID before and after authentication, allowing a fixated token to persist.
Accepting session IDs from URLs
Session tokens passed as URL query parameters can be injected by an attacker through crafted links.
Predictable session tokens
Weak or sequential session ID generation makes it possible for attackers to guess or pre-compute valid tokens.
Permissive cookie scope
Cookies scoped too broadly (e.g. parent domain) allow attackers on subdomains to set session cookies for the main application.
How to detect it
Automated detection
- SecPortal's authenticated scanner checks whether session IDs change after successful login flows
- Cookie attribute analysis detects missing HttpOnly, Secure, and SameSite flags on session cookies
- SAST tools identify session management code that lacks regeneration calls after authentication
Manual testing
- Set a known session ID before authenticating and verify whether it persists after login
- Attempt to pass session tokens via URL parameters to test if the application accepts them
- Inspect Set-Cookie headers for proper scope, flags, and entropy of session identifiers
How to fix it
Regenerate session ID on authentication
Always issue a new session identifier after successful login. Invalidate the old session to prevent reuse of pre-authentication tokens.
Reject externally supplied session IDs
Never accept session identifiers from URL parameters or form fields. Only use server-generated cookies for session management.
Set HttpOnly, Secure, and SameSite flags
Configure session cookies with HttpOnly to prevent JavaScript access, Secure to require HTTPS, and SameSite=Strict to block cross-site requests.
Implement session timeout
Set absolute and idle session timeouts to limit the window of opportunity for fixated sessions to be exploited.
Compliance impact
Test session security automatically
SecPortal checks cookie flags, session regeneration, logout effectiveness, and concurrent session handling. Start free.
No credit card required. Free plan available forever.