# Session hijacking and cookie theft

> Cookie theft is copying the login cookie your browser keeps after you sign in, letting an attacker use your account without your password or 2FA. How to stop it.

Canonical: https://www.phishclean.com/threats/session-hijacking-attacks
Last updated: 2026-10-09

You log into your bank account, grab coffee from the kitchen, and come back two minutes later. Everything looks normal. But someone on the other side of the world is already inside your account, moving money. They never needed your password. They just stole your session.

In 2010, a developer named Eric Butler released Firesheep, a Firefox extension that let anyone on a public WiFi network hijack other people's Facebook, Twitter, and Amazon sessions with a single click. No hacking skills required. It was downloaded over a million times in the first week and forced most major websites to roll out HTTPS by default.

## What is cookie theft?

**Cookie theft is copying the session cookie a website keeps in your browser after you sign in, and using it to get into your account from somewhere else.** That cookie is the reason you don't have to log in again on every page. Whoever has a copy is, as far as the website can tell, you: no password needed, and no two-factor code, because both were checked once, at login, and the cookie is the proof that they were. Session hijacking is the name for what the attacker does next.

The way it usually happens now isn't a hacker on café Wi-Fi. It's **infostealer malware**: a program, typically hidden in a cracked game, a fake software update, an email attachment or a [rogue browser extension](https://www.phishclean.com/blog/can-a-browser-extension-steal-my-login-session), that copies every cookie and saved password out of your browsers in a few seconds and uploads them. The stolen cookies are sold in bulk on criminal marketplaces, and buyers load them into their own browser to skip the login entirely. Security people call this "pass-the-cookie".

In March 2023 the Linus Tech Tips YouTube channel, with more than 15 million subscribers, was taken over this way. A staff member opened what looked like a sponsorship offer; the attachment was malware that copied the browser's session tokens, and the attackers used them to get into the channel without the password or two-factor codes, then ran crypto-scam streams on it.

Browsers are pushing back. Since Chrome 127 in July 2024, Chrome on Windows encrypts cookies with a key tied to Chrome itself ([App-Bound Encryption](https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html)), so other programs can't simply read them. And since May 2026, Google sign-ins in Chrome on Windows use [Device Bound Session Credentials](https://workspaceupdates.googleblog.com/2026/05/prevent-account-takeovers-with-DBSC-now-generally-available-in-the-Chrome-browser-for-Windows.html), which tie the session to a key in the computer's security chip, so a copied cookie stops working on another machine within minutes. Neither covers every site or every browser yet, which is why the habits below still matter.

**If you think your cookies were stolen:** changing your password is not enough on its own, because the stolen cookie may still be valid. Use the account's "sign out of all devices" or active-sessions page (Google, Microsoft, Facebook, Instagram, Amazon and most banks have one) to end every session, then change the password and scan the computer for malware. If malware was involved, do the password changes from a different, clean device.

## How session hijacking actually works

Here's what most people don't realize about web authentication: your password only matters once. When you log in, the server creates a session — a temporary token (usually stored in a cookie) that proves you are who you say you are. Every request after that just sends the cookie. No password, no two-factor code. Just the cookie.

Session hijacking is the act of stealing that cookie and using it from another browser. The attacker doesn't break into your account. They *become* you.

And there are more ways to pull this off than you'd expect.

### The five main attack vectors

- **Packet sniffing on public WiFi** — On an unencrypted network (or a network where [HTTPS has been stripped](https://www.phishclean.com/threats/ssl-stripping-attacks)), an attacker can read every cookie your browser sends. Tools like Wireshark make this trivial.
- **Cross-site scripting (XSS)** — If a website has an XSS vulnerability, an attacker can inject a script that reads `document.cookie` and sends it to their server. One line of JavaScript is all it takes.
- **Malware and rogue browser extensions** — Malicious software running on your machine can extract cookies directly from your browser's cookie store. Some extensions request permissions that give them full access to every cookie on every site.
- **Physical access to an unlocked browser** — If someone can sit down at your unlocked laptop, they can open DevTools, copy your session cookies, and paste them into their own browser. Takes about 15 seconds.
- **Session fixation** — Instead of stealing your session token, the attacker gives you one they already know. If the server accepts a pre-set session ID without regenerating it after login, the attacker is already in.

### The attack flow looks like this:

**You Log In** Server issues session cookie

→

**Attacker Steals Cookie** XSS / sniffing / malware

→

**Attacker Uses Cookie** Server thinks it's you

## Why session hijacking is so dangerous

Here's what most people miss: the attacker doesn't need your password. They don't need to bypass two-factor authentication. They don't need to answer your security questions. The session cookie *is* the authentication.

Once an attacker has your session token, they can:

- Read your emails and send messages as you
- Change your account settings, including your password and recovery email
- Make purchases or transfer money from your bank
- Access every service you're currently logged into
- Download private files, photos, and documents

And the server has no way to tell the difference. From its perspective, the attacker's requests look identical to yours — same cookie, same session, same permissions. Unless the server is doing extra checks (like binding the session to your IP or device fingerprint), there's no alarm.

Most websites don't invalidate sessions when they detect a new IP address or device. They prioritize convenience over security. That means a stolen session cookie often works for hours or even days after it's taken.

## Real-world examples

**Firesheep (2010)** was the wake-up call. Before it, session hijacking on WiFi was theoretically known but practically ignored. Eric Butler's Firefox extension turned it into a point-and-click attack. You'd sit in a coffee shop, open Firesheep, and see a wall of profile pictures — each one a Facebook, Twitter, or Amazon session you could take over with one click. The tool didn't exploit any bug. It just read cookies from unencrypted WiFi traffic. That's all it needed.

The fallout was massive. Facebook, Twitter, and Google all accelerated their HTTPS rollouts. But Firesheep proved a critical point: if the transport layer isn't encrypted, session cookies are public information.

**Session tokens in URLs** are another real-world vector that still exists. Some older web applications pass session IDs as URL parameters (`?sessionid=abc123`) instead of cookies. This means the session token shows up in browser history, server logs, analytics platforms, and — worst of all — the HTTP Referer header sent to every external link on the page. Clicking a link to another site leaks your entire session. Honestly, it's 2026 and some applications still do this.

## How PhishClean detects session exposure

PhishClean can't stop every session hijacking attack — if malware has root access to your machine, no browser extension can save you. But PhishClean catches several of the most common ways sessions get exposed in the first place.

Here's what it monitors:

- **Tokens in localStorage (TOKEN_STORAGE_PATTERN signal)** — Storing auth tokens in `localStorage` instead of HttpOnly cookies makes them accessible to any JavaScript on the page. A single XSS vulnerability means game over. PhishClean detects patterns that match JWT tokens, API keys, and session identifiers stored in localStorage.
- **JWTs in URLs (JWT_URL signal)** — When JSON Web Tokens appear in URLs, they leak through the Referer header, browser history, and server logs. PhishClean flags this immediately because it's one of the easiest session exposure vectors to exploit.
- **HTTPS downgrades (HTTPS_DOWNGRADE signal)** — If a page [downgrades from HTTPS to HTTP](https://www.phishclean.com/threats/ssl-stripping-attacks), cookies without the Secure flag get sent in plaintext. PhishClean detects these downgrades before your cookies are exposed.
- **Auth headers to third parties (AUTH_HEADER_THIRD_PARTY signal)** — Sometimes web applications accidentally send authorization headers (Bearer tokens, API keys) to third-party domains — analytics services, CDNs, or tracking pixels. PhishClean detects when authentication credentials are being sent somewhere they shouldn't be.

All of this runs locally in your browser. PhishClean never sees your tokens, your cookies, or your session data. It pattern-matches against known risky behaviors and alerts you before the exposure can be exploited.

## How to protect yourself

If you're a developer building web applications, the fix is straightforward (even if the implementation takes discipline):

- **Set the HttpOnly flag on session cookies.** This prevents JavaScript from reading the cookie, which shuts down XSS-based session theft entirely. It's one flag. There's no reason not to set it.
- **Set the Secure flag.** This tells the browser to only send the cookie over HTTPS. If the connection gets [downgraded to HTTP](https://www.phishclean.com/threats/ssl-stripping-attacks), the cookie stays in the browser. Simple and effective.
- **Use the SameSite attribute.** Setting `SameSite=Strict` or `SameSite=Lax` prevents the browser from sending cookies on cross-site requests, which defends against cross-site request forgery and reduces exposure in [hidden iframe attacks](https://www.phishclean.com/threats/hidden-iframe-attacks).
- **Keep session timeouts short.** A session that expires after 30 minutes is a much smaller target than one that lasts 30 days. Yes, users have to log in more often. That's the tradeoff.
- **Regenerate session IDs after login.** This kills session fixation attacks. When a user authenticates, throw away the old session ID and issue a new one.
- **Enforce HTTPS everywhere.** No exceptions. Not for images, not for scripts, not for "static" pages. Any HTTP request is an opportunity for cookie theft.

If you're a regular user, your best moves are: use a VPN on public WiFi, keep your browser updated, audit your extensions (remove anything you don't actively use), and lock your screen when you walk away. Small habits, big impact.

## Related threats

- [SSL stripping attacks](https://www.phishclean.com/threats/ssl-stripping-attacks): HTTPS downgrades expose session cookies in plaintext on public networks.
- [Phishing attacks](https://www.phishclean.com/threats/phishing-attacks): Phishing pages can harvest credentials that lead to session takeover.
- [Hidden iframe attacks](https://www.phishclean.com/threats/hidden-iframe-attacks): Invisible iframes can load authenticated pages and steal session data.
- [Formjacking](https://www.phishclean.com/threats/formjacking-attacks): Injected scripts steal form data, including tokens and credentials on the page.

## Frequently asked questions

What is cookie theft?

Cookie theft is stealing the session cookie a website stores in your browser after you log in. That cookie is what keeps you signed in, so whoever holds a copy can use your account from their own computer without your password and without a two-factor code. Today it is mostly done by infostealer malware, which copies the cookies out of the browser and sells them.

Can session hijacking happen on HTTPS sites?

Yes. HTTPS protects the cookie in transit, but session hijacking doesn't always happen over the network. Cross-site scripting (XSS) attacks can steal cookies directly from the browser, malware can extract them from disk, and if a session token leaks into a URL or gets logged somewhere, HTTPS won't help. HttpOnly and Secure cookie flags reduce the risk, but they're only effective if every part of the application sets them correctly.

Does clearing cookies prevent session hijacking?

Clearing cookies ends your current sessions, which limits the window an attacker has to use a stolen token. But it doesn't prevent hijacking — it only shortens how long a stolen session stays valid. The real defenses are HttpOnly cookies, short session timeouts, and binding sessions to device fingerprints so stolen tokens can't be replayed from a different browser.

How do I know if my session has been hijacked?

Common signs include being unexpectedly logged out (because the server invalidated your session after the attacker used it), seeing unfamiliar activity in your account, receiving alerts about logins from unknown locations, or noticing settings changes you didn't make. Many services offer an "active sessions" page where you can see every device currently logged in. Check this regularly — if you see a session from a location or device you don't recognize, revoke it immediately and change your password.

## Catch session exposure before attackers do

PhishClean monitors for insecure token storage, JWT leaks, and HTTPS downgrades — all locally in your browser. No tokens are uploaded for detection.

[Install PhishClean](https://www.phishclean.com/#install)

Last updated: 9 October 2026