Cross-Site Request Forgery (CSRF)
CSRF tests whether a state-changing request can be forged from another origin using the victim's ambient session. The exam focuses on finding actions that lack unpredictable, session-bound anti-CSRF protection and on understanding modern cookie defences.
Core rules and concepts
- Exploitation needs an authenticated victim, predictable request parameters, automatic credential attachment (cookies), and no validated unpredictable token.
- Defences: synchronizer tokens bound to the session, SameSite=Lax or Strict cookies, Origin/Referer validation, a required custom header, and re-authentication for sensitive actions.
- SameSite=Lax allows cookies on top-level GET navigations, so GET-based state changes remain vulnerable. Strict blocks cross-site sending; None requires Secure.
- Simple requests (form posts, image loads) can be sent cross-origin; reading the response requires CORS. JSON endpoints sometimes still parse
text/plainform bodies. - Login CSRF and method-override parameters are valid variants.
Worked example
An email-change action is POST /account/email with email=x&csrf=<token>. Remove the csrf parameter entirely; the server still returns 200 and the email changes. Reasoning: the token is validated only when present, so omission bypasses the check. If removal fails, try substituting another user's token; acceptance proves the token is not bound to the session. Build a PoC HTML page with a hidden form targeting the endpoint and auto-submitting it. Confirm in a browser with a logged-in session and verify the change server-side.
Traps that cost marks
- Assuming only POST is vulnerable; GET-based state changes still work with SameSite=Lax.
- Missing tokens that are present but optional, static, or not session-bound.
- Testing while logged out, which produces meaningless failures.
- Confusing CSRF with CORS: CSRF is about sending forged requests; CORS misconfiguration is about reading responses.
- Forgetting that JSON endpoints may accept form-encoded content types.