While logged in to a banking site in one tab, a user clicks a forum link that silently submits a funds-transfer form to the bank. The bank processes it because the browser automatically attached the user's session cookie, and no script ever ran on the bank's own pages. Which attack is this?
Select an answer to reveal the explanation.
Short Explanation
Think of someone slipping a signed check into a pile of papers you're already signing — your signature is real, but the request isn't yours. That's cross-site request forgery: your browser's cookie vouches for a request you never meant to make. The trap is XSS; nothing ran inside the bank's pages here.
Full Explanation
Cross-site request forgery exploits the fact that browsers attach cookies to every request sent to a site, regardless of which page triggered it. A malicious page on another origin can auto-submit a form or load a crafted URL aimed at a state-changing endpoint; if the user holds an active session, the target server sees a properly authenticated request and acts on it. The attacker never reads the response and never runs code in the target's origin, which is the key distinction. Defenses include anti-CSRF tokens tied to the session, SameSite cookie attributes, and re-authentication for sensitive actions such as transfers. Stored and reflected cross-site scripting both inject script that executes within the vulnerable site's origin, letting the attacker read data or act inside the page; the scenario states no script ran on the bank's pages. Session fixation forces a victim to use a session identifier the attacker already knows, then hijacks it after login; here the attacker never obtains the session at all. Exam caveat: XSS can be used to defeat CSRF tokens, so XSS on the same site undermines CSRF defenses. Operational check: verify that the transfer endpoint requires a per-session anti-CSRF token and that the session cookie carries SameSite=Lax or Strict.