🧪 Labs › Client-Side
Cross-Site Request Forgery (CSRF)
Severity: Medium
Make a logged-in victim's browser send a state-changing request they never intended.
What it is
CSRF abuses the fact that browsers attach a user's cookies to requests automatically. If a sensitive action is driven by a predictable request and protected only by the session cookie, an attacker's page can make the victim's browser fire that request while they're logged in.
Change an email, transfer funds, add an admin — all without the attacker ever seeing the victim's session.
The defence is proving the request came from your own app, not just from an authenticated browser.
How to approach it
- Find a state-changing request and work out exactly what it contains.
- Check what, if anything, ties the request to your app — an anti-CSRF token, a custom header, SameSite on the cookie.
- Test whether the action still succeeds when that protection is missing, altered, or supplied cross-site.
- Reason about whether an external page could reproduce the request against a logged-in victim.
Your task
Change another user's account setting by getting their authenticated browser to submit the request.
▶ Access the labOpens your hosted RatCTF instance. Work on it directly — there's nothing to submit here; you'll know when you've solved it.
How to prevent it
- Require an unpredictable anti-CSRF token on every state-changing request, verified server-side.
- Set SameSite on session cookies and check Origin/Referer for sensitive actions.
- Don't rely on the session cookie alone to prove intent.
More Client-Side labs
- Prototype Pollution — Poison the base object every other object inherits from, and change behaviour everywhere.
- Web Cache Deception & Poisoning — Trick the cache into storing the wrong thing — then serve it to everyone.