CSRF Mechanics

Web applications often rely on user authentication to control access, but this can be exploited through Cross-Site Request Forgery (CSRF). CSRF attacks trick authenticated users into performing unintended actions (e.g., changing passwords, transferring funds) by leveraging their existing session cookies. The attacker’s goal is to intercept and execute state-changing requests without the user’s knowledge. This section explains the mechanics of CSRF exploits, including token manipulation and interception of sensitive requests.

---

How CSRF Exploits Work

A CSRF attack requires three key components:
1. Authenticated user session: The victim is logged into the target application.
2. Malicious request: The attacker crafts a request that alters server-side state (e.g., updating a profile or transferring money).
3. Browser context: The victim’s browser executes the malicious request, including their session cookies, without their awareness.

Example Scenario: Password Change

An attacker might embed a hidden form in a malicious website that submits a password change request to the target app. When the victim visits the malicious site, their browser automatically sends the request, using their session cookies to authenticate.

<!-- Malicious HTML snippet (e.g., in an image tag or iframe) -->
<form action="https://target-app.com/change-password" method="POST">
  <input type="hidden" name="newPassword" value="hacked123">
  <input type="hidden" name="username" value="victim@example.com">
</form>
<script>
  document.forms[0].submit();
</script>

---

Token Manipulation and Anti-CSRF Mechanisms

Modern applications mitigate CSRF by using anti-CSRF tokens—unique, unpredictable values tied to the user’s session. These tokens are typically included in forms or headers and validated server-side.

Token Binding and Validation

• Token generation: The server generates a random token (e.g., csrf_token=abc123) and stores it in the user’s session.
• Token inclusion: The token is embedded in the request (e.g., as a hidden form field or X-CSRF-Token header).
• Validation: The server checks if the token in the request matches the session-stored token. If not, the request is rejected.

Exploitation Without Tokens

If the application lacks anti-CSRF tokens, an attacker can bypass authentication entirely by submitting crafted requests. For example:

curl -X POST https://target-app.com/transfer \
  -d "amount=10000" \
  -d "toAccount=attackerBank" \
  -H "Cookie: session=valid_session_cookie"

---

Intercepting State-Changing Requests

CSRF attacks focus on state-changing requests (e.g., POST, PUT, DELETE) that alter server-side data. Attackers often use techniques like:
- Form submission: Embedding malicious forms in phishing emails or websites.
- JavaScript/AJAX: Using fetch() or XMLHttpRequest to send requests without user interaction.
- Image tags: Leveraging <img src="malicious-request"> to trigger requests.

Example: JavaScript-Driven CSRF

// Malicious script injected via XSS or a third-party widget
fetch('https://target-app.com/delete-account', {
  method: 'POST',
  headers: {
    'X-CSRF-Token': 'stolen_token_from_session'
  }
});

---

Mitigation and Defense Strategies

1. Use anti-CSRF tokens and validate them server-side.
2. Implement SameSite cookies to prevent cross-site request forgery (e.g., SameSite=Strict).
3. Validate request origins using headers like Origin or Referer.
4. Monitor and log suspicious activity (e.g., unexpected state changes).

---

Key takeaways

• CSRF exploits leverage authenticated sessions to execute unintended actions.
• Anti-CSRF tokens are critical for preventing token-based CSRF attacks.
• State-changing requests (e.g., POST, PUT) are the primary targets for CSRF exploitation.
• Defense requires a combination of token validation, cookie attributes, and request origin checks.