Session Hijacking
An attack where a hacker steals a user's session ID and uses it to impersonate them.
Detailed Explanation
Attackers typically steal session IDs through XSS, network sniffing (on unencrypted HTTP), or 'session fixation'. Once the attacker has the session ID (usually stored in a cookie), the server cannot distinguish them from the legitimate user. Defenses include using HTTPS, setting the `HttpOnly` and `Secure` cookie flags, and implementing session timeouts.
Quick Summary
Session hijacking is when an attacker steals a logged-in user's session token and impersonates them. The server can't tell the difference, it sees the right cookie, so it answers as if the real user asked.
Key Takeaways
- Common theft vectors: XSS reading non-httpOnly cookies, network sniffing on HTTP, malware on the user's machine, leaked logs containing tokens.
- Defenses: HTTPS everywhere, `HttpOnly` + `Secure` + `SameSite` cookie flags, short session TTLs, IP/device binding for sensitive operations.
- Session fixation is the variant where the attacker plants a known session ID into the victim's browser before they log in.
- Rotate the session ID on login and on privilege change to defeat fixation.
- Long-lived sessions are a tradeoff between UX and breach impact, pair with re-auth for sensitive actions.
When to use it
- Designing cookie security for any web app holding user sessions.
- Incident response: revoke all sessions for a user once compromise is suspected.
- Auditing logs for the same session token from multiple IPs or user agents, a classic theft signal.
- Step-up auth on detected anomalies (new device, new country) instead of trusting the cookie alone.
Common Mistakes
- Setting cookies without `HttpOnly`, XSS instantly reads the session ID via `document.cookie`.
- Mixing HTTP and HTTPS, so the session cookie crosses the wire in cleartext.
- Not rotating session IDs on login, leaving fixation attacks viable.
- Allowing sessions to live for months without re-auth, so one theft is one year of access.
Session Hijacking, Frequently Asked
Does SameSite cookie prevent session hijacking?
It prevents one class, CSRF and cross-site cookie leaks. It doesn't stop XSS, network sniffing, or malware. SameSite is necessary, not sufficient.
Should I bind sessions to IP address?
Tempting but fragile, mobile users hop networks constantly, breaking the session and frustrating them. Better to bind to device fingerprint or trigger step-up auth on anomaly, rather than hard-fail on IP change.