↓ Skip to main content
Dinh Tuan Kiet
/
  1. Writeups/

[PortSwigger] Cross-Site Request Forgery (CSRF) Series

Table of Contents

Welcome to the Cross-Site Request Forgery (CSRF) research series within the PortSwigger Web Security Academy writeup collection.

Cross-Site Request Forgery (CSRF) is a client-side vulnerability where an attacker induces an authenticated user’s browser to perform unintended, state-changing actions on a trusted web application. By exploiting the browser’s default behavior of automatically including session cookies with cross-site HTTP requests, an adversary can forge actions such as modifying account email addresses, altering passwords, transferring funds, or executing administrative commands.

1. Core Prerequisites for CSRF
#

For a CSRF attack to succeed against a target endpoint, three foundational conditions must be satisfied:

  1. A Relevant Action: The application must process a sensitive, state-changing action (e.g., modifying user profile data, altering credentials, managing permissions).
  2. Cookie-Based Session Handling: The application must rely entirely on browser-managed session cookies to authenticate incoming requests, without verifying secondary transport-layer tokens or authorization headers.
  3. No Unpredictable Request Parameters: The requests required to execute the action must contain no values that an attacker cannot determine or guess (e.g., absence of cryptographically secure anti-CSRF tokens).

2. Series Challenge Index
#

The table below catalogs all 11 practical challenges across Apprentice and Practitioner levels, detailing their primary vulnerability mechanisms and real-world exploitation impact:

LabChallenge NameLevelPrimary Vulnerability MechanismExploit Impact
1CSRF vulnerability with no defensesApprenticeApplication lacks anti-CSRF tokens and SameSite cookie restrictionsUnauthenticated email modification via crafted HTML form
2CSRF where token validation depends on request methodApprenticeToken verification enforced strictly on POST but omitted for GET requestsMethod conversion bypass to change victim email
3CSRF where token validation depends on token being presentApprenticeServer validates token integrity only if present in request parametersToken parameter omission to bypass verification
4CSRF where token is not tied to user sessionPractitionerGlobal token pool validation without binding tokens to user session IDsToken harvesting from attacker session to forge victim requests
5CSRF where token is tied to non-session cookiePractitionerToken tied to custom tracking cookie combined with cookie injectionInjecting matching csrfKey cookie to validate stolen token
6CSRF where token is duplicated in cookiePractitionerNaive Double Submit Cookie pattern without server-side state verificationCookie injection (via search/CRLF) to set synchronized pseudo-token
7SameSite Lax bypass via method overridePractitionerTop-level navigation sends Lax cookies combined with _method overrideConverting POST to GET navigation via form method override
8SameSite Strict bypass via client-side redirectPractitionerSame-site client-side redirect gadget triggers secondary request with Strict cookiesChaining client-side redirect to bypass Strict cookie boundaries
9SameSite Strict bypass via sibling domainPractitionerVulnerable sibling domain (XSS) within same registrable domain (eTLD+1)Cross-subdomain exploitation to trigger authenticated requests with Strict cookies
10CSRF where Referer validation depends on header being presentPractitionerServer verifies Referer domain if present but skips check when header omittedOmitting Referer header via <meta name="referrer" content="no-referrer">
11CSRF with broken Referer validationPractitionerFlawed regex or substring matching on Referer header (indexOf or partial match)Appending target domain to query parameter of attacker exploit host

3. Defense Taxonomy & Bypass Vectors
#

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

flowchart TD
    A["Cross-Site Request Forgery (CSRF) Defenses"] --> B["Anti-CSRF Tokens"]
    A --> C["SameSite Cookie Restrictions"]
    A --> D["Referer Header Validation"]

    B --> B1["Method Dependency (Bypass via GET)"]
    B --> B2["Omission Dependency (Bypass via Removal)"]
    B --> B3["Session Decoupling (Global Pool Hijack)"]
    B --> B4["Double Submit Cookie (Cookie Injection via CRLF/Search)"]

    C --> C1["SameSite=Lax (Method Override Gadget)"]
    C --> C2["SameSite=Strict (Client-Side Redirect Gadget)"]
    C --> C3["Sibling Domain Inheritance (Cross-Subdomain XSS)"]

    D --> D1["Header Omission (no-referrer Policy)"]
    D --> D2["Partial Substring Matching (Query Parameter Spoofing)"]

4. Defense-in-Depth Remediation Principles
#

Modern enterprise defenses against CSRF combine multiple layers of verification:

  1. Synchronizer Token Pattern (CSRF Tokens):
    • High-entropy, cryptographically random, per-user-session tokens.
    • Enforce server-side validation strictly across all state-changing HTTP verbs (POST, PUT, DELETE, PATCH).
  2. Modern SameSite Cookie Attributes:
    • Enforce SameSite=Strict or SameSite=Lax on all authenticated session cookies.
    • Guard against top-level GET transitions and method-override routing gadgets.
  3. Custom Request Headers:
    • Enforce custom headers (e.g., X-Requested-With, Authorization: Bearer <token>) on REST and JSON APIs, requiring cross-origin preflight checks (CORS).
  4. Interactive Confirmation for Sensitive Operations:
    • Re-authenticate users (password entry) or require Multi-Factor Authentication (MFA) prior to high-risk transactions (email modification, password changes, fund transfers).

2026