CSRF Lab: Make a Victim’s Bank Send You Money

This article describes a CSRF (Cross-Site Request Forgery) lab exercise where an attacker crafts a malicious webpage that silently submits a bank transfer form to a victim's logged-in session without their knowledge. The lab demonstrates how browsers automatically attach session cookies to requests, allowing attackers to perform unauthorized state-changing actions on behalf of authenticated users. Understanding CSRF is critical because it exploits a fundamental browser behavior to compromise account security, and the article shows both how the attack works and how to defend against it.

• Core CSRF mechanism and browser cookie behaviorCSRF succeeds because browsers automatically attach cookies to any request sent to the site that set them, regardless of which page initiated the request. An attacker creates a form on their controlled page with fields matching the target site's transfer endpoint, pre-fills it with malicious values (like attacker's account and $9,999), and makes it submit silently when the victim loads the page. The victim's browser includes their QuickBank session cookie with this cross-site request, causing QuickBank to accept it as a legitimate, authenticated action.
• Why the attacker needs no token or response accessCSRF works without the attacker reading the response because same-origin policy prevents cross-origin responses from being readable by JavaScript. For state-changing actions like transfers or email changes, simply sending the properly-formatted request is sufficient—the attacker doesn't need to see QuickBank's response to know the transfer succeeded. This contrasts with attacks like XSS that require reading sensitive data, making CSRF particularly effective against financial transactions.
• QuickBank's vulnerable implementationQuickBank uses only a session cookie to identify the user and contains no anti-CSRF token or origin validation on its transfer endpoint. This means every value in the transfer request (recipient, amount, user identity) is either guessable or already public, and there is nothing secret or unpredictable that an attacker must obtain. A form on any other site can exactly reproduce the bank's transfer request and succeed when the victim's browser automatically supplies the session cookie.
• Historical prevalence and modern defense shiftsCSRF was significant enough to hold its own entry in the OWASP Top 10 until 2017, but its prevalence declined due to two major changes: frameworks now include anti-CSRF tokens by default, and browser behavior evolved so that since 2020 Chrome treats cookies without a SameSite attribute as SameSite=Lax, which blocks most cross-site POST requests. However, CSRF still exists in custom code, legacy applications, cookie-based APIs, and anywhere protection has been explicitly disabled.
• Three-layer defense strategyThe article recommends three complementary defenses: use anti-CSRF tokens (synchroniser tokens) on every state-changing form and request, set the SameSite attribute on session cookies (at least Lax, Strict for sensitive operations), and check the Origin or Referer header as an additional validation layer. Additionally, state-changing operations should never use GET requests, and sensitive actions like transfers should require re-authentication or second-factor confirmation.
• High-value testing targets in real applicationsWhen testing with permission, attackers should prioritize state-changing requests lacking CSRF tokens, particularly email changes, password changes, and adding payees. Email-change CSRF is especially dangerous because it often leads directly to account takeover through the password reset mechanism, making it a high-impact vulnerability to identify and remediate in real applications.
• Why origin validation alone is insufficientQuickBank's vulnerability persists because it checks only the session cookie to identify the user but does nothing to verify that the request originated from QuickBank's own pages. Without a secret anti-CSRF token that only legitimate pages know, the bank cannot distinguish its own form from a forged one on an attacker's site, even if origin checks are theoretically present.

Bottom line: CSRF succeeds because browsers silently attach cookies to cross-site requests, allowing attackers to forge state-changing actions on behalf of authenticated users without reading responses. Every application handling sensitive operations must implement anti-CSRF tokens, enforce SameSite cookie attributes, validate request origins, and require re-authentication for critical actions to prevent this attack.