Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is a subtechnique of Request Forgery where attackers trick authenticated users into executing unwanted actions on a web application. By exploiting the trust that a web application has in an authenticated user's browser, CSRF attacks can force users to perform state-changing operations like modifying account settings, making purchases, or transferring funds. The attack is particularly effective because the malicious requests include all the user's authentication tokens and cookies, making them appear legitimate to the target application.

Examples in the Wild

Notable CSRF Attacks:

0.0.0.0 Day CSRF Vulnerability (20+ Years Unpatched) A long-standing CSRF vulnerability, dubbed the "0.0.0.0 day", has remained unpatched for over two decades. The vulnerability allows malicious websites to bypass security in major browsers by exploiting how browsers handle certain DNS responses. This vulnerability demonstrates how fundamental web security assumptions can remain flawed for extended periods.

Drive-by Pharming Attack (2014) A massive CSRF campaign compromised over 300,000 home routers across multiple countries by exploiting router DNS settings. The attackers used cross-site request forgery vulnerabilities to modify DNS configurations on various router models including TP-Link, D-Link, Micronet, and Tenda. The attack was particularly sophisticated as it: - Overwrite DNS settings to redirect traffic to attacker-controlled servers - Used a secondary legitimate DNS (Google's 8.8.8.8) to avoid detection - Affected users were concentrated in Vietnam, India, Italy, and Thailand - Exploited routers that weren't using default passwords through CSRF

GitHub OAuth Token Exposure (2017) A CSRF vulnerability in GitHub's OAuth implementation allowed attackers to steal users' OAuth tokens by tricking them into visiting malicious websites. The attack could expose repository access tokens and potentially lead to source code theft or malicious code injection. GitHub's post-mortem revealed that missing state validation in the OAuth flow enabled the attack.

Router Configuration Attacks Multiple router manufacturers have been affected by CSRF vulnerabilities that allowed attackers to modify DNS settings, enable remote access, or change admin passwords through malicious websites. Notable examples include: - ASUS Router CSRF (CVE-2014-9583) - D-Link Router CSRF (CVE-2019-13361) - TP-Link Router CSRF (CVE-2020-24586)

Banking Trojans with CSRF Several banking trojans have incorporated CSRF attacks to automate fraudulent transactions: - The Dridex malware used CSRF to initiate wire transfers - The Gozi trojan exploited CSRF to modify payment destinations - The TrickBot malware chain included CSRF for account takeover

Attack Mechanism

Common CSRF Exploitation Techniques:

1. Basic Form Submission

   <!-- Malicious HTML form -->
   <form action="https://bank.com/transfer" method="POST">
       <input type="hidden" name="amount" value="1000">
       <input type="hidden" name="to" value="attacker">
       <input type="submit" value="Click me!">
   </form>
   
   <script>
       // Auto-submit form on page load
       document.forms[0].submit();
   </script>
   

2. XMLHttpRequest Exploitation

   // CSRF via XHR
   function csrfAttack() {
       var xhr = new XMLHttpRequest();
       xhr.open("POST", "https://target.com/api/action", true);
       xhr.withCredentials = true;  // Send cookies
       xhr.setRequestHeader("Content-Type", "application/json");
       xhr.send(JSON.stringify({
           "action": "update_email",
           "new_email": "attacker@evil.com"
       }));
   }
   

3. Image-Based CSRF

   <!-- CSRF via image tag -->
   <img src="https://bank.com/transfer?amount=1000&to=attacker" 
        style="display:none" 
        onerror="this.style.display='none'">
   

Detection Challenges

Why Traditional Security Tools Fail:

1. Request Legitimacy

   # Request characteristics
   csrf_request:
     - cookies: "valid"
     - session: "authenticated"
     - origin: "different domain"
     # How to determine legitimacy?
   

2. Token Validation

   # CSRF token issues
   token_problems:
     - missing_token: "no protection"
     - predictable_token: "guessable"
     - token_reuse: "replay attacks"
     # How to ensure proper tokens?
   

3. Header Verification

   # Header validation
   security_headers:
     - origin: "sometimes missing"
     - referer: "can be spoofed"
     - custom_header: "not always present"
     # Which headers to trust?
   

Required Application Security Strategy:

# CSRF prevention rules
- rule: "Token Validation"
  condition: |
    request.has_valid_csrf_token AND
    token.not_expired AND
    token.matches_session
  severity: critical

# Origin verification
- rule: "Origin Check"
  condition: |
    request.origin_allowed AND
    request.referer_valid AND
    request.same_site_context
  severity: high

# Request validation
- rule: "Request Legitimacy"
  condition: |
    request.method_requires_protection AND
    request.state_changing AND
    request.authenticated_context
  severity: critical

Key Detection Requirements:

1. Token Management
2. Cryptographic token generation
3. Per-session token tracking

4. Token lifecycle management

5. Origin Validation

6. Strict origin checking
7. Referer validation

8. SameSite cookie enforcement

9. Request Analysis

10. Method verification
11. State change detection
12. Authentication validation

References & Resources

Official Sources:

1. OWASP CSRF Prevention Cheat Sheet
2. MITRE CWE-352
3. NIST Guidelines on CSRF

Technical Analysis:

1. PortSwigger Web Security Academy
2. GitHub Security Lab
3. Mozilla Web Security Guidelines