Session hijacking
In web and identity security, session hijacking is the theft and reuse of the token that proves a user has already logged in. The attacker never learns the password and never faces the login form: they present the stolen session and the application treats them as the user who created it.
How it works
After authentication the server issues a bearer of some kind, normally a cookie holding a session identifier or a signed token. From then on the credential is that value, not the password, and anyone holding it is the user until it expires or is revoked. Four routes get it. Script running on the origin reads it, which is cross-site scripting against a cookie without the HttpOnly flag. Malware on the endpoint takes it out of the browser profile, which is what an infostealer is built to do. A proxy sits between user and site and keeps the token as it passes, which is adversary-in-the-middle. Or the token leaks in a URL, a referrer header, a log or an error page.
What goes wrong
This is the technique that quietly removed the value of second factors as they are usually deployed. Multi-factor authentication protects the moment of login. A session issued after that moment is a single-factor credential for its whole lifetime, so an attacker who captures it has bypassed the second factor without ever attacking it.
The failures we report are mundane and consistent. Sessions that are not rotated at login, which allows fixation. Sessions that survive a password change, so the victim’s remediation does nothing. Long or sliding expiry with no absolute limit. No server-side revocation, which is common with stateless tokens, so logout is a client-side gesture. Cookies without HttpOnly, Secure or an appropriate SameSite value. And no binding at all between the session and any property of the client, so a token replayed from another country and another device is accepted without comment.
Where this shows up in an audit
We take a valid session from one browser, replay it from a separate machine and network, and record whether the application notices. Then we change the password, log out, and replay again, which is what tells the client whether their incident response would actually end an intrusion. The finding states the token, its lifetime, its flags, the revocation behaviour observed and what the replay achieved. This is part of how we test session handling end to end.