How does a Cross-Site Request Forgery (CSRF) attack work?
A malicious page makes the victim's logged-in browser fire a state-changing request to a trusted site; the browser auto-attaches the session cookie, so the request looks legitimate.
* CSRF — the attacker's hidden form makes the victim's logged-in browser POST to the bank with the session cookie auto-attached, so the forged transfer looks legitimate. *
CSRF attack flow:
- The victim logs into their e-bank; the bank sets a session cookie, say
JSESSIONID=A23dc… - In the same browser, still logged in, the victim opens the attacker's page and clicks something innocuous — a "CLICKME" button
- That page carries a hidden form aimed at the bank:
<form action="https://e-bank.com/doTransfer" method="POST">
<input name="fromAccount" value="VICTIMS_ACCOUNT">
<input name="toAccount" value="ATTACKERS_ACCOUNT">
<input name="amount" value="10000">
</form>
- The browser submits it and — because the request goes to
e-bank.com— automatically attaches the bank's cookies, session cookie included - The bank receives a well-formed, correctly authenticated transfer request and executes it
Key insight: the browser attaches a site's cookies to any request aimed at that site, no matter which page triggered it. So on the wire a forged request is indistinguishable from a genuine one, and the server has nothing to check.
What the attacker never gets: they cannot read the bank's pages or responses — the same-origin policy blocks that. CSRF is a write attack: it makes something happen (transfer, password change, purchase) while flying blind. That asymmetry is exactly what the defences exploit — every one of them requires the request to carry a value the attacker can trigger but not read.
Go deeper:
PortSwigger — CSRF — the mechanics; why auto-sent cookies make forged requests look legitimate.- CWE-352: Cross-Site Request Forgery (MITRE) — authoritative weakness definition.
- Wikipedia — Cross-site request forgery — worked examples, limitations, and the defence history.