Session hijacking: taking over a signed-in session

Session handling advice follows the OWASP Session Management Cheat Sheet.

HTTP does not remember anyone between requests. After a successful sign-in, the site creates a session on the server and hands the browser a long random value that names it: the session token, or session ID. The browser sends it back with every request, almost always in a cookie, and the site looks it up to know who is asking.

The token is a bearer credential: holding it is the whole proof. That is why it has to be unpredictable, kept out of places others can read, and short-lived. Tokens in other forms, such as signed tokens sent in an Authorization header, carry the same risk once they are stolen.

• Stealing the cookie with script. A cross-site scripting flaw lets attacker script read a cookie that is not marked HttpOnly and send it away.
• Sniffing it on the network. On a connection without TLS, anyone on the same network can read the cookie in transit; this is the old sidejacking attack on public Wi-Fi.
• Taking it from where it leaked. Tokens in URLs end up in logs, browser history and Referer headers sent to other sites.
• Stealing it from the device. Malware that copies browser cookies is now a common way in, and it bypasses multi-factor authentication because the session already passed it.
• Guessing or predicting it. Rare today, but possible when a token is short or built from predictable values.

In every case the attacker then sends requests with the token, and the site serves them as if the user had.

Session fixation works the other way round. Instead of stealing a token after sign-in, the attacker sets a token before it: by sending the victim a link that carries a session ID, or by planting a cookie through a related subdomain. The victim signs in, the site attaches the signed-in session to the token the attacker already knows, and the attacker uses it.

The fix is simple and decisive: issue a new session token at sign-in, and at every change of privilege, and never accept a session ID from a URL. OWASP lists reusing the same identifier after sign-in as an A07 failure.

Cookie attributes, defined in RFC 6265 and its successors, do most of the work:

• HttpOnly keeps the cookie away from page script, which blunts cookie theft through XSS.
• Secure sends it only over HTTPS, so it never crosses the network in clear text.
• SameSite=Lax or Strict limits when the browser attaches it to cross-site requests, which also helps against CSRF.
• A narrow Domain and Path, so sibling subdomains cannot read or set it.

1. Generate tokens with a proven session manager. Long, random, created on the server; never build your own.
2. Rotate the token at sign-in and privilege changes. This defeats fixation outright.
3. Set idle and absolute timeouts, and end sessions at logout. On the server, not only by deleting the cookie; this is CWE-613.
4. Keep tokens out of URLs. Cookies or headers only.
5. Re-check identity for sensitive actions. Asking for the password or a second factor before changing the email address or paying limits what a stolen session can do.
6. Let users see and end their sessions. A list of active sessions turns an unnoticed takeover into a visible one.

Some sites also tie a session loosely to the client, for example by noticing a sudden change of country or device. Such checks catch some theft and annoy some travellers; they belong in the application, next to the session itself. When a hijack succeeds, the result is account takeover.

Little directly. A request carrying a stolen token is byte for byte what the owner would send, so there is nothing to match. A filter helps one step earlier, by refusing requests that carry the script injection used to steal cookies, and limits can slow attempts to guess tokens.

Everything that decides whether a stolen token still works, its lifetime, its rotation, its cookie attributes, sits in the application.