csrf

Cross-Site Request Forgery Detection

Overview

Cross-site request forgery abuses ambient authority: the browser attaches the victim's session cookies to any request aimed at the application's domain, so a request generated by an attacker's page arrives fully authenticated and indistinguishable from a real one. The attacker cannot read the response — the same-origin policy still blocks that — so the goal is purely the side effect: change the account email and then take it over through password reset, change a password directly, move money, grant a role, delete a record. The attacker is a remote third party whose only requirement is that the victim visits an attacker-controlled or attacker-influenced page while their session is alive; when the victim is an administrator, forged administrative actions can compromise the whole application. Three conditions must hold for a request to be forgeable: a worthwhile state change, cookie-based session handling, and no request parameter the attacker cannot predict. This skill locates every state-changing entry point together with whatever defence claims to protect it, checks each one in parallel, and merges results into <output_dir>/csrf-results.md.

What it is NOT

• Cross-site scripting (/websec:xss): XSS runs attacker script inside the application's origin and can read responses — including reading a valid anti-forgery token straight out of the DOM, which defeats token defences entirely. Test: if the attacker executes JavaScript in the target's origin, it is XSS; if they can only cause a blind request from outside, it is this class. Report an XSS that trivially defeats the token under "Also observed" and let /websec:xss own it.
• Cross-origin resource sharing misconfiguration (/websec:cors): the two are constantly conflated in both directions. A permissive response header lets an attacker read a cross-origin response; it neither creates nor prevents forgery, and forgery needs no such header because a plain HTML form suffices. Test: does the attack depend on reading the body? Then it is /websec:cors.
• Clickjacking (/websec:clickjacking): the victim performs a real click on the authentic page inside a hidden frame, so the page supplies its own valid token. Test: does the attack require victim interaction with a framed copy of the real page? Then framing controls, not tokens, are the fix, and it belongs there.
• Broken access control (/websec:access-control): if the action should have been refused for this caller regardless of how the request was produced, the missing control is authorisation. Forgery assumes the victim is authorised and the attacker borrows that authority.
• Authorisation-code and state-parameter flaws (/websec:oauth): a missing state on a redirect-based authorisation flow is that skill's forgery variant, not this one.
• Open redirection (/websec:open-redirect): being bounced to an attacker's destination after the endpoint ran is that class; arriving at the endpoint cross-site and having it act is this one. Test: is the harm that the request fired without the victim's intent (here), or that a request-supplied next decided where the browser went afterwards (there)? A state-changing GET carrying a return parameter is often both — judge each half in its own skill.
• Cross-site socket hijacking (/websec:websockets): a handshake the attacker's page opens cross-site gives a two-way channel it can also read, and anti-forgery tokens play no part in the upgrade. Test: is the forged thing a cross-site request to an HTTP endpoint (here), or a cross-site socket handshake (there)?
• Ambient authority decided upstream: whether a browser's cookies ever reach this service can be a property of the deployment rather than of this code — a hop may terminate the browser session and forward a bearer credential, or pass the cookie straight through. Read the "Enforced where" column and the trust-boundary section of architecture.md before concluding either way, and where the answer cannot be read, classify NEEDS MANUAL REVIEW naming that configuration rather than reporting every mutating route. What is judged here: if cookies do arrive, this service needs a check of its own — an origin rule enforced at the edge is a control to read and judge, never one to assume.
• Not a finding: a genuinely side-effect-free GET; an endpoint that requires a secret the attacker cannot predict or obtain (a per-record nonce, a current-password field, a one-time code, a value that must be read from the current response); an action gated by re-authentication or step-up verification; a request that carries no ambient credential at all because authentication is a bearer token held in memory and attached by application code — note that a token stored in a cookie and attached automatically is ambient; an internal endpoint reachable only from a network the browser cannot address.