EXERCISE 3 — The three preconditions and a defence for each ============================================================ A CSRF attack needs ALL THREE of these. Remove any one and it fails. PRECONDITION 1 — Cookie-only authorization. The server authorizes the action based solely on the automatically-sent session cookie; it asks for nothing else to prove intent. EXAMPLE DEFENCE: Require a secret anti-CSRF TOKEN (synchronizer token, Chapter 5) in the request body/header that the server validates against the session — so the cookie alone is no longer sufficient. (Also: re-authentication / re-entering a password for sensitive actions, Chapter 8.) PRECONDITION 2 — Forgeable parameters. Every parameter the request needs is predictable, so the attacker can construct a complete valid request in advance. EXAMPLE DEFENCE: Include an unpredictable per-session/per-request token the attacker cannot know or guess (Chapter 5), or a double-submit cookie value echoed into a header (Chapter 6). The attacker can't supply the right value, so the request can't be forged. PRECONDITION 3 — Cross-site credentialed requests are sent. The browser will attach the victim's credentials (cookies) to a request triggered by another site. EXAMPLE DEFENCE: SameSite cookies (Chapter 7) — SameSite=Lax/Strict tells the browser NOT to send the cookie on cross-site requests, so the forged request arrives unauthenticated. (Also: Origin/Referer header checking, Chapter 8, rejects requests that didn't originate from your own site.) THE MENTAL MAP THIS BUILDS: precondition attacked by ------------ ----------- 1 cookie-only auth -> tokens / re-auth (Ch.5, Ch.8) 2 forgeable params -> unpredictable tokens (Ch.5, Ch.6) 3 cross-site creds -> SameSite / Origin checks (Ch.7, Ch.8) Notice defences 2 and 3 are the most common in practice (tokens + SameSite), and good apps layer several (defence in depth, Chapter 8). The rest of the course is essentially a detailed tour of these counters.