Cross-Site Request Forgery
web · easy · +30 XP
// what is Cross-Site Request Forgery?
Cross-Site Request Forgery (CSRF) = an attacker tricks an authenticated user's browser into firing a state-changing request to your site. The browser auto-attaches the user's session cookie, so the server thinks the user did it. Anti-CSRF tokens, SameSite=Lax/Strict cookies, and Origin/Referer checks all exist to defeat this — but they only help when applied correctly.
// how attackers detect it
- [01]Replay a sensitive request from a different origin (
curl -H 'Origin: https://evil.com'). Does it succeed? - [02]Strip the CSRF token / Origin header from the request. Does it still succeed? That's the bug.
- [03]Test cookie attrs —
SameSite=None; Securecookies are cross-site-trustable;SameSite=Laxblocks most POSTs.
// how defenders prevent it
- ✓Use
SameSite=Lax(orStrict) on session cookies. Modern browsers default to Lax — but verify. - ✓Synchroniser-token pattern: server-issued CSRF token in a header or hidden form field, validated server-side.
- ✓Validate the Origin header strictly and reject when it's missing on state-changing requests.
- ✓Sensitive actions (password change, payment) → require re-auth or step-up MFA regardless of CSRF token.
// real-world incidents
CVE-2023-26604
systemd-run CSRF-like privilege escalation
OS-level demonstration of trust-the-caller bugs.
CVE-2021-21971
VMware vCenter CSRF + RCE chain
Pre-auth on the management plane.
// hands-on tips for this lab
- ›The server only rejects when Origin is present and mismatches. Drop the header entirely (no
-H 'Origin: ...').
was this lesson helpful?