Course · Applications · 08 / 69
Session hijacking and cookie theft: how sessions are stolen and how to make them worthless
The ways a session token leaves the user — network sniffing, script access, infostealers, logs, and fixation — how cookie flags and server-side session design limit each one, and how to read a session in a capture or proxy.
Diagram
Where a session token can leak
Plain HTTP sends the cookie readable to anyone on the path; HSTS and Secure stop this.
# Wire # Plain HTTP sends the cookie readable to anyone on the # path; HSTS and Secure stop this.
HTTP allowed
No HttpOnly, no Secure
Months, no server revocation
The example on the open step is one illustration, or the fix you can paste into an application you own.
What this page is made of
A short map of the pieces. Each piece says what fails, who is affected, what you would notice, and what you change.
Fixation
- What fails
- If the id is not rotated at sign-in, a pre-set id becomes authenticated.
- Who is affected
- Users who sign in on a shared or prepared device.
- What you would notice
- The same session id before and after sign-in.
- What you change
- Issue a new id on every authentication change.
Reading a session in a capture
In a lab, capture traffic to a test application served over plain HTTP and filter in Wireshark with http.cookie. The cookie value is readable in the packet details, which is why HSTS and the Secure flag exist. Repeat over HTTPS and only the TLS handshake and encrypted records are visible.
wireshark display filter: http.cookie contains "session" Hypertext Transfer Protocol GET /dashboard HTTP/1.1 Host: lab-app.internal Cookie: session=8f3c19a2... <- readable because the lab app uses HTTP
Checking cookie flags
In browser developer tools under Application, Cookies, every session cookie should show Secure, HttpOnly, and a SameSite value. The __Host- prefix forces Secure, Path=/, and no Domain attribute, which stops subdomains from setting it.
When a session is stolen
Revoke the user’s sessions and refresh tokens server-side, check for mailbox rules or OAuth grants added during the hijack, and look for the infostealer on the device if cookies were taken locally. Resetting the password alone does not end an existing session unless the application revokes it.
Check yourself
Recognition and the fix. Nothing here is a procedure.
An infostealer copied a user’s browser cookies. Their password was then reset. Is the attacker locked out?
Go deeper
Specific techniques, exercises, and glossary cards for this topic.
- 01Rotate the session when sign-in succeedsA session id that survives sign-in was known before the person proved who they are. Includes the diagram and a defensive fix.
- 02Where a bearer token lives in the browserA token in local storage is readable by any script on the page. Includes the diagram and a defensive fix.
Exercises
- 01Control benchA copied session is still accepted. Choose the control that makes the copy expire and stay unreadable to scripts.
- 02Cookie flag simulatorSix Set-Cookie headers, six kinds of request. See which cookies the browser sends, which scripts can read, and which it rejects outright.