What is login CSRF against a clinic booking site, and why is signing a victim into the attacker's own account worth doing?

## The inversion Ordinary forgery uses the victim's session to perform an action in the victim's account. **Login CSRF** reverses both sides: the forged request carries the attacker's credentials, and the session that results belongs to the attacker but lives in the victim's browser. | | Ordinary forgery | Login CSRF | |---|---|---| | Whose credential travels | The victim's session cookie, attached by the browser | The attacker's username and password, typed into the hostile page's markup | | Must the victim be signed in first | Yes | No | | What the attacker gains | One action in the victim's account | Everything the victim does afterwards, in an account the attacker owns | | Where the attacker reads it | Nowhere — the attack is write-only | By signing into their own account later, at leisure | That last row is what makes it worth the trouble. The attacker never needs to read a response during the attack; they collect the results afterwards by signing in normally. ## How the forged sign-in is emitted Mechanically it is the plainest case in the whole subject: a cross-site form addressed at the clinic's sign-in endpoint, with the attacker's own account name and password as hidden fields. No session is required, no cookie needs to be attached, nothing has to be read. The clinic validates the credentials — they are valid, because they are the attacker's — and returns a `Set-Cookie` response header field. The browser stores it for the clinic. The victim is now signed in as somebody else. ## What the victim then contributes On a clinic booking site the harvest is specific and unpleasant: 1. **A payment card**, saved to "their" account for future invoices. 2. **Pet records** — species, age, conditions, the practice they attend. 3. **Appointments**, which also reveal where the victim will physically be and when. 4. **Messages to the practice**, which people write candidly. 5. **A changed password** if the victim tries to tidy up the account — which, if the form does not demand the current password, locks the attacker out but only after the data has accrued. On other kinds of site the same shape yields search history, uploaded documents or purchases billed to the attacker's stored card to an address the attacker chooses. ## Why it gets missed Three reasons, and all three are worth saying out loud in an interview: - **The endpoint runs before authentication**, so it does not look like a protected surface. Provenance checking is often applied only to endpoints behind the session check. - **No victim credential is involved**, so an audit that hunts for "requests carrying a session" will not flag it. - **The victim may not notice.** People do not re-read the account name on every page, and a site that greets them by first name may simply be greeting somebody else's. The tell, when a victim does notice, is that the site seems to have forgotten them: empty history, an unfamiliar name in the corner, a pet list that is not theirs. ## The variant where the victim is already signed in If the owner happens to be signed in when the forged sign-in fires, the clinic replaces their session with the attacker's in place, and the switch is silent apart from the account name in the corner of the page. The victim is mid-task — halfway through booking a vaccination — and simply carries on inside an account that is not theirs. That variant is narrowed by ending any existing session when a sign-in succeeds, which is worth doing on its own merits. It does nothing for the more common case, where the victim had no session at all and no reason to expect one to appear. ## The lesson Login CSRF is the cleanest demonstration that forgery is a **provenance** problem, not an authentication problem. There is no session to steal and no credential to protect, and the attack still works, because the clinic acted on a request without knowing what caused it. A sign-in endpoint is a state-changing endpoint like any other — it writes a session — and it needs the same class of check every other state-changing endpoint needs. Which check, and where it runs, is the defence material's business; recognising that the sign-in form is in scope at all is this one's.