Session hijacking

Session hijacking exploits the stateless nature of HTTP: because the protocol does not remember a user between requests, a server issues a session identifier after authentication and thereafter trusts any request bearing it. In classic web applications this identifier is an opaque session ID stored server-side and carried in a cookie; in modern token-based systems it may be a bearer token such as a JWT or an OAuth 2.0 access/refresh token. Whoever presents a valid, unexpired session artefact is treated as the authenticated user, which is the crux of the attack - the credential being replayed is not the password but the proof-of-login the system minted afterwards. This is why hijacking bypasses even strong authentication and most MFA: those checks happened before the token was issued.

The token can be obtained in several ways. Cross-site scripting (XSS) is the predominant route for stealing cookies via injected script, unless the cookie is marked HttpOnly (which blocks script access); network interception applies where traffic is unencrypted, largely closed off by ubiquitous TLS; malware or malicious browser extensions can read cookie stores directly on the endpoint; and adversary-in-the-middle phishing proxies relay a real login to capture the resulting session in real time. Related but distinct are session fixation, where the attacker sets a known session ID before the victim logs in (defeated by regenerating the ID on authentication), and cross-site request forgery, which rides an existing session without stealing the token. In the OWASP Top 10:2025 these belong to A07 Authentication Failures.

Defences layer around protecting, binding and expiring the session. Cookies should carry the HttpOnly, Secure and an appropriate SameSite attribute; the session ID must be long, random and regenerated on privilege changes; and idle and absolute timeouts limit the token's useful life. Because a stolen bearer token is inherently replayable, high-assurance systems move toward proof-of-possession or token-binding schemes (such as DPoP for OAuth) that cryptographically tie the token to a client key, and continuous or risk-based re-evaluation that invalidates a session when context shifts - a new IP, device or geolocation. This continuous verification is a core Zero Trust idea: authentication is not a one-time gate but an ongoing assessment.

A key misconception is that MFA prevents session hijacking; it protects the login event, not the session that follows, so stolen-cookie attacks are precisely how attackers sidestep MFA, and the mitigations must target the token itself. Another is assuming HTTPS makes cookie theft impossible; TLS stops network sniffing but not XSS, endpoint malware or phishing-proxy capture. Session hijacking is the consequence that a man-in-the-middle position or an XSS flaw enables, and it stands adjacent to credential theft: stealing the password lets an attacker log in, while stealing the session lets them skip logging in entirely.