Cross-Site Request Forgery (CSRF)

CSRF is a web security vulnerability that tricks authenticated users into executing unintended actions on a web application. Attackers exploit the trust a site has in a user's browser, leveraging active sessions to perform actions without the user's consent.

Key Points

• Targets authenticated sessions – Only works if the victim is logged into the target application
• Exploits automatic credential submission – Browsers send cookies/tokens with every request
• No credential theft needed – Uses existing sessions rather than stealing passwords
• Affects state-changing operations – Common targets include fund transfers, password changes, or account deletions

---

How CSRF Attacks Work

Attack Sequence

Step	Actor	Action
1	User	Logs into a legitimate site and receives a session cookie
2	Attacker	Crafts a malicious request (e.g., a hidden form or image)
3	Attacker	Delivers the request via email, message, or a malicious site
4	User's Browser	Automatically includes authentication cookies in the request
5	Web Application	Processes the request as legitimate due to valid credentials
6	Web Application	Executes the unintended action (e.g., transfers funds)

Common Attack Vectors

• Malicious links – Disguised in emails or messages
• Embedded images – <img> tags with src pointing to an action URL
• Hidden forms – Auto-submitting forms on attacker-controlled sites
• Cross-origin requests – AJAX calls from malicious domains

---

Prevention Techniques

Anti-CSRF Tokens

• How it works: Unique, unpredictable tokens are generated per session/request.
• Implementation:
  • Server embeds a token in forms (e.g., <input type="hidden" name="csrf_token" value="...">).
  • Server validates the token on state-changing requests.
  • Requests without valid tokens are rejected.

SameSite Cookie Attribute

Restricts when cookies are sent with cross-site requests:

Value	Behavior
Strict	Cookies only sent for same-site requests (most secure)
Lax	Cookies sent for top-level navigation (default in modern browsers)
None	Cookies sent for all requests (requires Secure flag)

Additional Defenses

• Re-authentication – Require passwords for sensitive actions (e.g., fund transfers).
• Header validation – Check Referer or Origin headers (secondary defense).
• Custom headers – Require headers that cross-origin requests cannot set.
• Double-submit cookies – Send tokens as both cookies and request parameters.

---

Real-World Example

Scenario: A banking app lacks CSRF protection.

• Attack: An attacker sends a victim an email with:

  <img src="https://bank.example/transfer?to=attacker&amount=1000" width="0" height="0">
  

• Result: The victim's browser automatically includes their session cookie, and the bank processes the transfer.
• With Protection: The bank rejects the request if it lacks a valid CSRF token.

---

Testing for CSRF Vulnerabilities

• Manual checks:
  • Remove/modify CSRF tokens in requests.
  • Test requests from different origins.
  • Verify token randomness and expiration.
• Automated tools:
  • Burp Suite – Intercept and modify requests.
  • OWASP ZAP – Automated scanning.
  • CSRFTester – Specialized detection.

---

Best Practices

• Use multiple defenses (e.g., tokens + SameSite cookies).
• Apply protections to all state-changing operations.
• Leverage framework-built-in defenses (e.g., Django, Spring Security).
• Educate users to log out of sensitive apps when inactive.
• Audit regularly for vulnerabilities.

---

Learn More

• OWASP CSRF Prevention Cheat Sheet
• PortSwigger CSRF Guide
• MDN SameSite Cookies