Session Hijacking: How Stolen Cookies Bypass Passwords and MFA — and the Flags That Stop It

Key Takeaway

• 🍪 Session hijacking steals the cookie, not the password: after you log in, the session cookie IS your identity to the server — whoever copies it speaks as you with no password prompt and no MFA challenge.
• 📡 The capture routes are mundane: unencrypted HTTP on open Wi-Fi, XSS scripts reading cookies, malicious extensions, malware holding the browser, and session fixation — every route ends with the same copied credential of trust.
• 🚩 The three flags that stop most theft: HttpOnly (scripts can’t read the cookie), Secure (HTTPS-only transit), SameSite (no cross-site rides) — the OWASP session cheat sheet’s baseline, and the reason plain HTTP sessions are an anachronism.
• 🧹 The user-side habits: logout that actually logs out (server-side), session/device lists reviewed, extension grants audited, and no banking rides on HTTP pages — the cookie never re-encrypts itself.
• 🚨 Suspected theft has an order: revoke all sessions server-side, rotate the password and linked tokens, sweep the entry vector — a browser-side cookie delete does nothing to a copied token.

Session hijacking is the quiet bypass behind some of the biggest account takeovers: the attacker never cracks your password because they never need it — they copy the session cookie your browser already earned and present it as their own. CISA’s MFA guidance flags the category by effect (a stolen session defeats the second factor by construction), the OWASP session management cheat sheet prescribes the cookie flags that neutralize the main capture routes, and the breach record — the British Airways attack that rode injected JavaScript to 380,000 payment records and a $230 million fine — shows the scale a successful hijack reaches. This guide decodes the attack in plain terms, lists the capture routes with their fixes, and gives the user-side habits and the response order when a cookie is already copied.

What a Session Actually Is — and Why the Cookie Is the Identity

Session hijacking starts from a bargain: the password proves you once, and the server issues a session identifier — stored in a cookie — that says “already proven” on every later request. The server stops re-asking; the cookie answers for you. That design is why the web is usable, and why session hijacking is so clean: to the server, a request carrying a valid session cookie simply IS the user, from whichever machine it arrives. The literature’s phrase for it — the cookie is the receipt for authentication already passed — explains session hijacking in one line: multi-factor authentication happens at login, the cookie is the proof-of-pass, and a copied receipt works at any till. This is also why session hijacking feels invisible: no failed logins, no password lockout, no MFA challenge — just a shadow user reading your inbox alongside you.

Session Hijacking: The Five Capture Routes

1. Network sniffing over HTTP. On open Wi-Fi, a cookie sent without the Secure flag travels readable — anyone positioned on the network path can copy sessions in transit; the historic Firesheep tool made the point brutally, and the fix (TLS everywhere, Secure flag, HSTS) is now baseline.
2. XSS and malicious scripts. Injected JavaScript reads the cookie out of the page and ships it to the attacker’s server — the route behind the British Airways case; the HttpOnly flag exists precisely to close script access to session cookies.
3. Malicious extensions and malware-in-browser. An extension with broad permissions can read page context and exfiltrate tokens; infostealer malware families harvest entire cookie jars from infected laptops precisely because a fresh session cookie outvalues an MFA-protected password.
4. Session fixation. The attacker plants a session ID they already know, then lets the victim authenticate into it — the fix is servers regenerating the session ID at every login and privilege change.
5. Weak or predictable session IDs. Sequential or low-entropy identifiers get guessed — the fix is cryptographically random generation, a server-side property users can only verify indirectly through the vendor’s posture.

The Flags Explained: HttpOnly, Secure, SameSite

The OWASP session management cheat sheet collapses most of the defense into three cookie attributes, and each one answers a specific route. HttpOnly: scripts cannot read the cookie — the XSS exfiltration lane dies with the attribute (though a script still inside your authenticated page can act as you, so it narrows rather than ends XSS harm). Secure: the cookie travels only over HTTPS — network sniffing loses its lane. SameSite (Strict or Lax): the cookie doesn’t ride cross-site requests — confused-deputy, CSRF-style rides close down. The __Host- prefix adds belt-and-braces: the browser enforces Secure, prevents scoping by subdomain, and pins the path. None of these is user-configurable — they are properties the SERVICE sets, which reframes the user question: your posture against session hijacking at a website is limited to the habits below plus choosing services that treat session hygiene seriously. Server-side operators run shorter sessions than feel comfortable and rotate identifiers on every login and privilege change, because a stolen cookie that expires in hours is an incident; one that lasts a month is an occupation.

Session Hijacking On Your Side: The Habits That Matter

• Log out with consequence. Logging out should invalidate the session server-side, not just delete the cookie — on accounts that matter, verify by watching the session/device list (Gmail, Microsoft, and most estates expose one): a logout that clears your list did its job.
• Never let core accounts ride HTTP. The padlock before entering credentials is table stakes; the Secure flag keeps LATER requests safe, but a site that redirects to HTTP mid-session is leaking — the hotel-Wi-Fi DNS-hijack guide shows the network-side variant of exactly this loss.
• Audit extensions and grants quarterly. The browser extension you granted years ago holds live page access still — the same session-reading surface an XSS payload wants — and the routine sweep lives in our browser-hijacker removal guide.
• Watch public Wi-Fi for sensitive sessions only after verifying HTTPS end to end — and prefer a VPN for anything financial; the home-Wi-Fi hardening guide covers the network’s half of the bargain.
• Keep devices clean. Infostealer malware harvesting cookies is now an economy; the scan-and-update discipline the tech-support cleanup order enforces is the cookie-jar defense.

Suspected Session Theft: The Response Order

1. Revoke sessions server-side. Sign out “everywhere” from the account’s security page — a copied cookie may keep working if only the browser cookie was deleted, so the server-side invalidation is the real move.
2. Rotate the password and linked tokens — session theft doesn’t prove password exposure, but the capture route (a page script, an extension, malware) usually does; rotate from a clean device.
3. Read the activity log for the stolen window: what was read, sent, or changed — and reverse or flag it.
4. Close the entry vector: uninstall the extension, run the full scan, clear the site data — the route that copied the cookie must die before new sessions are worth having.
5. Re-authenticate fresh and re-enroll stronger factors where offered — passkeys remove the copied-cookie problem entirely by binding the credential to the device.

Frequently Asked Questions

Session Hijacking — Can It Really Bypass Multi-Factor Authentication?

Yes — and that is its defining property. MFA proves the user at login; the session cookie is the lasting proof the login already happened. Copy the cookie and every authenticated request replays without a password or an MFA challenge, which is why CISA’s guidance treats session theft as a distinct bypass from credential attacks and why the cookie flags plus short session lifetimes matter as much as strong authentication.

How would I know my session was hijacked?

Usually too late for symptoms — the shadow user works quietly inside your authenticated session. The catches: unfamiliar entries in the account’s session/device list, “you were signed out” messages you didn’t cause, outbound-mail or activity-log entries you don’t recognize, and — for estates — the denial-storm-then-approval signature our MFA fatigue guide documents for the push side. When doubt lingers, revoke the session and rotate — the session hijacking playbook has no gentler setting.

Does HTTPS everywhere make session hijacking impossible?

No — it closes one route. TLS in transit stops network sniffing, but script-based theft (XSS, malicious extensions), malware-in-browser harvesting, and fixation survive full HTTPS. The cookie flags (HttpOnly, Secure, SameSite) close more lanes, and browser hygiene closes the rest — HTTPS is the floor of the defense, not the ceiling.

Public Wi-Fi: is logging in still risky if the site uses HTTPS?

Far less risky than the pre-HTTPS era, but not zero: verify the padlock holds on every page of the session (the Secure flag applies only while the connection does), watch for browser certificate warnings and take them seriously, and add a VPN for anything financial — the network attacker who cannot read your cookie can still push you onto a fake page where you hand over the credentials fresh.

What’s the single most important cookie flag, and why?

HttpOnly, by the practitioners’ consensus: it removes the script-read-and-exfiltrate route in one attribute, and the XSS route is the most common capture path in documented incidents — the British Airways breach rode exactly that lane. Secure and SameSite close the transport and cross-site lanes behind it; all three plus rotation and short lifetimes is the baseline the OWASP cheat sheet prescribes for any session worth protecting.

Financial Disclaimer

This article provides general cybersecurity guidance and does not constitute professional security or financial advice. Session mechanisms, cookie standards, and platform security pages change over time and vary by service; verify every step against OWASP’s and each provider’s official documentation before acting. The author and publisher disclaim any liability for actions taken based on this information.