Skip to content

Cross-Site Request Forgery (CSRF)

Prerequisites

  • INSECURE-threat-intel-app running; signed in at http://localhost:8081.
  • Burp Suite (Burp basics).

Likeliness meter

Moderate — Reduced by SameSite cookies and frameworks with CSRF tokens; still appears on legacy forms and custom APIs.

Overview

Cross-Site Request Forgery (CSRF) tricks a victim’s browser into sending a request the victim did not intend, while the browser automatically attaches session credentials (usually cookies). The vulnerable server sees a valid logged-in request and performs a state change — change email, transfer funds, delete an account — because it cannot tell that the user did not click “Submit” inside the real app.

CSRF is not session hijacking (the attacker does not steal the cookie). The attacker rides the cookie by making the victim’s browser fire the right POST from another page or email link.

Defenses you should look for during testing:

  • CSRF tokens (synchronizer token in form + session)
  • SameSite cookies (Lax / Strict)
  • Custom headers required on APIs (X-Requested-With, Content-Type: application/json with CORS rules)

Settings (/settings) updates notification email via POST /api/settings/email with only the session cookie — no anti-CSRF token.

Learning objectives

  1. Inventory state-changing POST/PUT/DELETE requests in Burp.
  2. Confirm whether requests work without a CSRF token in Repeater.
  3. Demonstrate a cross-site proof-of-concept (same-origin PoC in this lab).
  4. Document in your lab report.

Attacker methodology

Step 1 — Hunt for state-changing endpoints (not every POST matters)

Browse the app with Burp HTTP history recording. Filter mentally (or with Burp display filter) for methods that change data:

Request State-changing? CSRF-relevant?
GET / dashboard No No
POST /api/auth/login Yes Usually not CSRF’d by design (attacker wants victim logged in)
POST /api/settings/email Yes Primary target for this guide

Dead end: Spending time on GET panel URLs — they should be idempotent and safe; no CSRF impact.

Step 2 — Identify a sensitive action in the UI

Open http://localhost:8081/settings.

Note the current notification email (e.g. analyst@projectx.lab). The form posts to:

POST /api/settings/email

Step 3 — Inspect the legitimate request in Burp

  1. Submit a benign email change in the browser: you.test@projectx.lab.
  2. Find POST /api/settings/email in HTTP history.
  3. Open the request and check:
Check In this lab
CSRF token field? None
Referer / Origin required? Not enforced for the PoC
Cookie sent? ti_session=...

Send to Repeater. Change email to another value and Send without touching cookies — if Burp still has the session cookie for localhost, the change succeeds. You have shown the server trusts cookie + POST body alone.

Step 4 — Repeater: prove the token is not required

In Repeater, remove any optional headers one at a time (except Cookie). Resend.

If the response is 302 back to /settings?updated=1 and the page shows the new email, document: “No CSRF token validation observed.”

Step 5 — Victim simulation: same-origin PoC page

Real attacks host HTML on an attacker domain. Modern SameSite=Lax cookies often block cross-site POST cookies — an important teaching moment. This lab includes a same-origin PoC so you can see the mechanism work:

  1. Stay logged in to http://localhost:8081.
  2. Open a new tab: http://localhost:8081/email-update.html (course PoC page; not linked in the app nav).
  3. The page auto-submits a hidden form to POST /api/settings/email with attacker-forged@evil.lab.
  4. Return to /settings — email should have changed without you clicking Save on the real form.

Burp: You may see the forged POST in HTTP history right after loading the PoC page. Compare it to your manual form POST — same endpoint, no token.

Tidbit: If you hosted the same HTML on http://evil.test, the browser might not send the session cookie on cross-site POST — note that in your report as a mitigating control that failed here because the PoC is same-site.

Step 6 — Attacker narrative (for your report)

While the victim is authenticated, visiting attacker-controlled content can change their notification email because /api/settings/email accepts cookie-authenticated POSTs without a CSRF token.

Step 7 — Report checklist

Field Example
Endpoint POST /api/settings/email
Sensitive action Change notification email
Missing control No CSRF token; no SameSite-only reliance tested on cross-origin
PoC /email-update.html
Impact Account takeover prep (password reset to attacker email)
Remediation CSRF tokens; SameSite=Strict for session; re-auth for sensitive changes

Remediation

  • Synchronizer token on all state-changing requests.
  • SameSite=Lax or Strict on session cookies (understand limits).
  • Re-authentication or custom headers for high-risk actions.