Session Fixation

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Broken Authentication / Session Management
Typical Severity High
OWASP A07:2021 – Identification and Authentication Failures
CWE CWE-384: Session Fixation
Also known as Session Riding (partial overlap), Session Hijacking via Fixation
Affected systems Web applications that accept externally supplied session identifiers and do not regenerate session IDs upon authentication
Relevant standards OWASP Session Management Cheat Sheet, NIST SP 800-63B

Overview

Session fixation is a class of session management vulnerability in which an attacker establishes a valid session with a web application, obtains the corresponding session identifier (session ID), and then tricks a victim into authenticating using that same session ID. Because the application does not issue a new session ID upon successful login, the attacker already knows the session ID the server will associate with the now-authenticated user and can immediately use it to impersonate the victim.

Unlike session hijacking, where the attacker must steal a session ID after authentication, session fixation requires only that the attacker supply the session ID beforehand. This distinction makes it exploitable even when network traffic is encrypted, provided the application allows session IDs to be injected through the URL, a hidden form field, or a cookie set by the attacker.

How it works

The attack follows a predictable sequence:

  1. Obtain a session ID. The attacker visits the target application and receives a valid, pre-authentication session ID (e.g., JSESSIONID=abc123).
  2. Deliver the fixed session ID to the victim. Common delivery mechanisms include:
    • A crafted URL with the session ID embedded as a query parameter (e.g., https://example.com/login?SESSIONID=abc123) — possible when the application accepts session IDs from the URL.
    • A sub-domain or same-site cookie injection if the attacker controls a sibling domain.
    • A man-in-the-middle position on an HTTP (non-TLS) connection, setting a Set-Cookie header directly.
    • Cross-site scripting (XSS) used to plant the session cookie value.
  3. Victim authenticates. The victim clicks the link, is presented with the login page, and logs in. The application authenticates the user but — critically — does not regenerate the session ID.
  4. Attacker accesses the authenticated session. Since the attacker already knows the session ID (they chose it), they can now send requests to the application using that ID and act as the authenticated victim.

Key technical preconditions that make an application vulnerable:

  • The application accepts session IDs supplied via URL parameters, hidden fields, or Set-Cookie headers from untrusted sources.
  • The application does not invalidate the existing session and issue a fresh session ID immediately upon a successful login (privilege escalation point).
  • Long-lived pre-authentication session tokens that do not expire quickly.

Business impact

A successful session fixation attack grants the adversary full control of the victim's authenticated session. Depending on the privilege level of the victim's account, this can result in:

  • Unauthorised data access or exfiltration — the attacker reads, copies, or downloads sensitive personal, financial, or proprietary data.
  • Account takeover — the attacker changes the victim's credentials, locking out the legitimate user.
  • Privilege escalation — if the victim is an administrator, the attacker gains administrative control over the application.
  • Fraudulent transactions — in e-commerce or banking applications, the attacker can initiate financial transactions on behalf of the victim.
  • Regulatory and compliance exposure — under GDPR, PCI DSS, and HIPAA, a breach facilitated by session fixation may trigger mandatory breach notification, fines, and audit obligations.
  • Reputational damage — users whose accounts are compromised lose trust in the application and the organisation.

How to fix it

  1. Regenerate the session ID upon authentication. This is the primary and most critical control. Immediately after a successful login (or any privilege-level change), invalidate the existing session and create a new one with a freshly generated, cryptographically random session ID. Most frameworks provide a dedicated method (e.g., session_regenerate_id(true) in PHP, request.getSession(false); request.getSession(true); in Java EE, Session.Abandon() + new session in ASP.NET).
  2. Reject externally supplied session IDs. Configure the application to never accept session IDs from URL query parameters or HTTP request bodies. Session IDs must only be accepted from cookies set by the server itself.
  3. Use secure, HttpOnly, and SameSite cookie attributes. Mark session cookies with Secure (HTTPS only), HttpOnly (inaccessible to JavaScript), and SameSite=Strict or SameSite=Lax to reduce the attack surface for cookie injection and XSS-based fixation.
  4. Set short session expiration for pre-authentication sessions. Pre-authentication sessions (before login) should expire quickly (e.g., within a few minutes of inactivity) to reduce the window during which a fixed session ID remains valid.
  5. Enforce TLS everywhere. Mandate HTTPS for all pages, including login forms, to prevent network-level injection of session cookies.
  6. Implement additional session binding. Optionally bind sessions to secondary identifiers such as the client's IP address or User-Agent string. While these can be circumvented, they add friction for attackers. Do not rely on them as the sole control.
  7. Audit framework defaults. Verify that your web framework's default session management does not accept URL-embedded session IDs and that session regeneration on login is enabled. Many frameworks disable URL-based session tracking by default but confirm this in your specific configuration.

Sensagraph automatically detects session fixation indicators, including applications that accept session IDs from URL parameters and fail to rotate session tokens at authentication boundaries.

References

Frequently asked questions

Session hijacking is a broad term for any technique used to take over an authenticated session, typically by stealing an existing session ID (e.g., via XSS, network sniffing, or cookie theft). Session fixation is a specific subtype where the attacker does not need to steal the session ID — instead, they supply a known session ID to the victim before authentication and then use it after the victim logs in.

HTTPS prevents network-level injection of session IDs by encrypting traffic, but it does not prevent session fixation on its own. If an application accepts session IDs from URL parameters, or if an attacker can set a cookie via a sub-domain or XSS, HTTPS provides no protection. The primary fix is always server-side session ID regeneration upon login.

Vulnerability depends on configuration rather than the framework itself. Older PHP applications are commonly affected because PHP's default session handling used to allow session IDs in URL parameters (via the PHPSESSID query parameter). Modern frameworks like Django, Rails, Spring Security, and ASP.NET Core regenerate session IDs on authentication by default, but misconfiguration or custom session handling can reintroduce the vulnerability.

Yes. If the application accepts session IDs from URL query parameters, an attacker can craft a malicious link containing a known session ID and send it to the victim via email, social engineering, or a redirect. The victim clicks the link over HTTPS, logs in, and the attacker already knows the session ID. Network encryption is irrelevant in this vector.

No. Cross-Site Request Forgery (CSRF) tricks an authenticated user's browser into making unintended requests using their existing session. Session fixation is a prerequisite attack that allows the attacker to take over the session itself; once the session is fixed and the victim authenticates, the attacker directly controls the session rather than forging requests from the victim's browser.