csrf-token-bypass-techniques

CSRF Token Bypass Techniques

When to Use

• When testing web applications that perform state-changing actions (password changes, email updates, transfers)
• When evaluating the robustness of anti-CSRF tokens and defenses
• During bug bounty hunting to chain vulnerabilities (e.g., Clickjacking to CSRF, Self-XSS to stored XSS via CSRF)
• When reviewing API implementations handling cookie-based sessions without proper headers

Prerequisites

• Authorized scope and target URLs from bug bounty program
• Burp Suite Professional (or Community) configured with browser proxy
• Familiarity with OWASP Top 10 and common web vulnerability classes
• SecLists wordlists for fuzzing and enumeration

Workflow

Phase 1: Identification & Baseline Testing

# 1. Identify state-changing requests
# Look for POST/PUT/DELETE requests that modify data (e.g., Update Profile)
# Ensure the session relies on Cookies (if it strictly uses Authorization: Bearer tokens in headers, it's generally not vulnerable to pure CSRF)

# 2. Test for anti-CSRF presence
# Generate a CSRF PoC using Burp Suite (Right-click request -> Engagement tools -> Generate CSRF PoC)
# Save as HTML, open in a different browser authenticated as the victim.
# If it works immediately, there is no CSRF protection.

# 3. Analyze the token
# Does the application use a hidden field, a custom header (X-CSRF-Token), or dual-submit cookies?

Phase 2: Token Validation Bypasses

# If the token is present and blocking the request, test these common implementation flaws using Burp Repeater:

# Bypass 1: Remove the token entirely
# Delete the CSRF token parameter/header from the request.
# Flaw: The backend often only validates the token IF it is present.

# Bypass 2: Change the request method
# Change POST to GET (Right-click -> Change request method).
# Flaw: The framework might enforce CSRF protection only on POST requests, but the endpoint might accept GET parameters.

# Bypass 3: Modify the token length/format
# Delete one character from the token or submit a blank value (csrf="").
# Submit an invalid token of the same length to ensure validation is actually occurring.

# Bypass 4: Token tying to user session
# Log in as Attacker, grab Attacker's valid CSRF token.
# Log in as Victim, use Attacker's token in Victim's request.
# Flaw: The token pool is global and not tied to the specific user's session cookie.

# Bypass 5: Double Submit Cookie Flaws
# If the app uses Double Submit (Token in Cookie == Token in Body)
# Can you set a cookie on the target domain (via sub-domain takeover, HTTP header injection, or XSS)?
# If yes, inject your own known token into the victim's cookie, and use that same token in the CSRF form.