A customer logged in to an online banking site opens a forum post in another browser tab. A hidden form on the forum page automatically submits a funds-transfer request to the bank, and the browser attaches the customer's valid session cookie. The bank's own pages were not modified, and the request was newly generated. Which attack occurred?
Select an answer to reveal the explanation.
Short Explanation
Here the attacker never touches your cookie; they just trick your browser into mailing the bank a request with your signature already on it. That's cross-site request forgery. Don't pick replay, since the request was brand new, and don't pick hijacking, since nobody stole the cookie.
Full Explanation
Cross-site request forgery causes an authenticated user's browser to send an unwanted, state-changing request to a site that trusts that browser. Because browsers automatically attach the site's cookies to requests sent to it, a hidden form on an unrelated page can submit a transfer that the bank processes as if the customer had initiated it. The attacker never sees the cookie or the response; the attack works by riding on existing authentication. A replay attack captures a legitimate message and resends it later, but the stem states the request was newly generated by the forum page. Session hijacking requires the attacker to obtain the session token and use it from their own system, whereas here the token stayed in the customer's browser. Stored cross-site scripting would require malicious script to be saved on the bank's site and executed in its context, yet the bank's pages were not modified and the malicious content lived on a third-party forum. Exam caveat: forgery leverages trust the site places in the browser, while cross-site scripting leverages trust the browser places in the site. Operational check: verify that state-changing endpoints require anti-forgery tokens, set session cookies with the SameSite attribute, and require reauthentication or transaction confirmation for transfers.