🍪 Session hijacking

A stolen session cookie IS the session, to a server that only checks the bearer value. Cookie hardening, binding, and detection are the defense.

This is a SELF-CONTAINED SANDBOX. The "session" you mint and replay below is an INERT token — it grants no real access anywhere in the Lab and is meaningless to the real login path. It exists only so this page's own replay check can demonstrate detection safely. Your REAL session already has its own new-context defense — c5 device recognition on the trusted-devices page, correlated by a real ITDR detector — this lab is a teaching simulator alongside that, not a replacement for it.

Learn → Session hijacking — when the cookie is the crown jewel Learn → Sessions — cookies, revocation & lifetime Learn → ITDR — detecting the attack, not just blocking it

🔒 Cookie hardening — proven live

This page just read document.cookie in your OWN browser, right now. Compare it against the real session cookie's reported policy below.

document.cookie, as seen by this page's JavaScript

Server-reported cookie policy (from the real cookie's own flags)

🎭 Steal it

Mint a sandbox token bound to THIS context's coarse browser/OS fingerprint. It's shown once, exactly like a token an XSS payload might exfiltrate.

🕵️ Replay it as the attacker

Present the stolen token again. Picking a different browser simulates the thief replaying it from their OWN machine.

Replay from

🗂️ Your sandbox sessions

None minted yet.

The defenses, all real

HttpOnly / Secure / SameSite — the real session cookie is invisible to page JavaScript, never sent in the clear, and never rides along cross-site. Proven live above, not asserted.
Fingerprint binding — a sandbox session remembers the coarse browser/OS family of the context that minted it. Deliberately coarse: an ordinary version bump won't false-positive. Not cryptographic — a determined attacker who spoofs a matching User-Agent defeats it; a production binding needs DBSC, OAuth Token Binding, or DPoP (this Lab already has DPoP for API tokens).
Hijack detection — a fingerprint mismatch on replay raises a real session_hijack alert an instructor triages on /soc, exactly like every other ITDR signal in the Lab.
Revoke — the response to a detected (or merely suspected) hijack: kill the session outright.

X-ray

🩻 X-ray — what actually happened

Your own insert-only audit trail — the real server events, sanitized (never a secret), each linked to the lesson that explains it.