Logged into someone else's account
A Socratic walk-through of logged into someone else's account — reasoned out one step at a time, not lectured.
The question we started with
THE QUESTION #How can an attacker harm you by making sure you are signed in rather than signed out?
Most attacks we imagine involve something being taken from us: a password guessed, a cookie stolen, an account locked. So here is an odd shape. An attack in which the attacker wants you to log in successfully, with your own correct password, into your own real account — and is harmed by nothing going wrong for you at all.
That sounds like it should not work. If the password never leaked and the login succeeded normally, what is left for an attacker to hold? The answer turns on a distinction that is easy to slide past: authenticating a session and choosing the name of the session are two different acts, and most applications quietly let the wrong party do the second one.
Reasoning it through
REASONING #Recall what a session identifier is: an unguessable value that the server maps to "this browser is that user". It is a bearer credential — present it and you are treated as the user it names.
So an attacker needs a valid identifier that names an authenticated session. There are two routes to one. The obvious route is to obtain it after the fact: read it off the network, steal it with a script, lift it from a log. Call that hijacking, and notice it depends on getting access to a secret you were not given.
The other route inverts the timing. What if the attacker supplies the identifier before you log in, and lets you do the work of making it valuable? That only works if the application makes a particular assumption, so ask what the assumption is.
Here it is. Most applications hand out a session the moment you arrive, long before any login — to hold a shopping cart, a locale preference, a form token. Then, when authentication succeeds, the natural implementation is to mark that existing session as authenticated. The identifier is unchanged; only its privileges rose. And that is the flaw in one sentence: an identifier chosen while the visitor was anonymous is carried across a privilege boundary.
Now, how does an attacker get a value of their choosing into your browser? Older applications accepted a session identifier from a URL parameter, so a crafted link was enough. That has largely been closed off, but cookies have a subtler weakness that is worth stating precisely: cookies have confidentiality protection from TLS but almost no integrity protection. A cookie set for a parent domain by any subdomain is returned to the main site, and the main site cannot tell which host set it. A neglected subdomain, or a network position on a plain-HTTP one, is enough to plant a value. The __Host- cookie prefix exists to close exactly this hole, by refusing any cookie that carries a Domain attribute or arrives without Secure.
So what is the fix? You could try to detect the attack — compare addresses, fingerprint the device — but that is a guessing game against a signal you do not control. The better move removes the assumption instead of catching the attacker: on successful authentication, generate a brand-new session identifier and invalidate the old one. The planted value now names an anonymous, abandoned session and is worth nothing.
Note the general shape of that, because it recurs. The strong fix did not identify anybody as malicious. It made the precondition the attack requires impossible to satisfy. The same rotation belongs at every privilege change — login, logout, a step-up to a sensitive area, a password change.
One point about perception, since it is what makes this attack durable. Nothing in your experience differs. No warning, no failed login, no unfamiliar page. You are correctly signed in to your own account. The attacker is simply a second, silent tenant of the same session, and there is no surface anywhere in your interface where that fact is represented.
The analogy
THE ANALOGY #Someone hands you a blank luggage tag and asks you to use it, having memorised the number printed on it. You write your own name on it, in your own hand, and attach it to your own bag. Every fact on the tag is true and yours. But the conveyor system does not read names — it reads the number, and they know the number.
a luggage tag is a visible object you consciously accept from a stranger, whereas a planted cookie arrives silently and the browser presents it on your behalf without ever showing it to you, so there is no moment at which you could decline.
Clarifying the model
THE MODEL #Three clarifications.
First, distinguish fixation from hijacking. Hijacking steals a value the victim already holds; fixation supplies a value the victim will make valuable. Fixation is the more dangerous of the two to reason about, because it needs no secret to leak.
Second, "regenerate the session" means more than issuing a new cookie value. The old identifier must be actively invalidated on the server. If both remain live, the attacker still holds a working credential and nothing has been fixed.
Third, and worth being careful about: HttpOnly and SameSite do not stop this. HttpOnly prevents a script from reading a cookie, and fixation never needs to read one. SameSite restricts when a cookie is sent cross-site, not who may set it, and its scope is the registrable domain — so a sibling subdomain counts as same-site. These attributes are genuinely valuable against other attacks; they are simply aimed elsewhere.
A picture of it
THE PICTURE #How to readFollow one value, not one user. Both branches leave the same state, with the same planted identifier and the same successful login by the same victim — the only difference is whether the application let that identifier survive the transition from anonymous to authenticated. The whole vulnerability, and the whole fix, live on that single edge.
What became clearer
WHAT CLEARED #The attack is not on your password or on your session's secrecy; it is on the moment your session gained authority. If an identifier chosen while you were nobody is still in force once you are somebody, then whoever chose it is somebody too — and rotating that identifier at the privilege boundary is what makes the question of who chose it stop mattering.
Where to go next
ONWARD #- Cookie integrity versus confidentiality, and what the
__Host-and__Secure-prefixes actually enforce. - Why subdomains are so often the weak point in an otherwise well-defended origin.
- Binding a session to a device-held key, so that possession of the identifier alone is not enough.
Key terms
TERMS #| Term | What it means |
|---|---|
| Session fixation | an attack in which the attacker sets or predicts a victim's session identifier before login and relies on the application not changing it afterwards. |
| Session hijacking | obtaining a victim's existing session identifier after it has been issued. |
| Session regeneration | issuing a new identifier and invalidating the old one whenever the session's privilege level changes. |
| Cookie tossing | setting a cookie for a parent domain from a subdomain the attacker controls, exploiting the lack of cookie integrity. |
Every term the collection defines is gathered in the glossary.