Cross-Site Request Forgery (CSRF) - Hunter Knowledge Base

A logged-in victim's browser is tricked into sending a state-changing request; the app trusts the ambient cookie and performs the action as the victim. Requires cookie-based auth and a missing anti-CSRF control.

Preconditions to confirm first

1. The endpoint performs a state change (create/update/delete/transfer/settings).
2. Auth is via ambient credentials (session cookie / HTTP Basic), not a per-request header token that JS must attach (Authorization: Bearer) - pure Bearer-in-header APIs are generally not CSRF-able.
3. There is no effective anti-CSRF defense on that route.

Sinks / patterns (grep targets)

State-changing route handlers (POST/PUT/PATCH/DELETE, or GET that mutates) that:

• lack CSRF middleware/decorator, or explicitly disable it: csrf_exempt, @csrf.exempt, skip_before_action :verify_authenticity_token, csrf: false, Spring .csrf().disable(), Express without csurf, SameSite=None/absent on the session cookie.
• Grep: csrf_exempt|verify_authenticity_token|csrf().disable|csurf|SameSite|@csrf.

Detection recipe

1. From codebase-map.json, list state-changing endpoints and their auth mechanism.
2. Check the global CSRF posture: is protection enabled framework-wide? Then find per-route exemptions.
3. Check cookie flags: SameSite=Lax/Strict blocks most cross-site POSTs; SameSite=None re-opens it.
4. Confirm the endpoint doesn't already require a non-ambient token or a custom header (which forces a preflight and blocks simple cross-site requests).

Payloads / PoC

• Auto-submitting form: an HTML page with <form action="https://target/settings" method="POST"> and hidden inputs, plus <script>document.forms[0].submit()</script>; victim visiting it triggers the action.
• For JSON endpoints that accept text/plain or don't check content-type: a form with enctype="text/plain" crafting a JSON-ish body.
• GET-based state change: <img src="https://target/delete?id=5">.
• PoC = the victim, while logged in, loads the attacker page and the state change occurs.

False-positive filters

• Anti-CSRF token required and validated (synchronizer token, double-submit cookie) on the route.
• SameSite=Lax (default in modern browsers) or Strict on the session cookie - mitigates most CSRF; note residual risk for top-level GET navigations under Lax.
• Auth is a header token the browser won't auto-attach cross-site (Bearer), not a cookie.
• Endpoint requires a custom header (forces CORS preflight) and CORS is not permissive.

CWE / OWASP / severity

CWE-352. OWASP A01:2021. Severity by action impact: account/email/password change or money transfer -> high; low-value toggles -> medium/low.

Chaining hints

CSRF + xss (steal token then forge) ; CSRF to change email/password -> account takeover; CSRF to add an attacker OAuth/app -> persistence; often combined with access-control to hit privileged actions.

Mitigation

Enable framework CSRF protection on all state-changing routes (don't blanket-exempt); require a synchronizer or double-submit token; set session cookies SameSite=Lax/Strict + Secure; prefer non-ambient auth for APIs; require a custom header for JSON APIs and lock down CORS.