Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is a web security vulnerability that exploits the trust a web application has in an authenticated user's browser. Attackers trick victims into unknowingly executing malicious actions on web applications where they're currently logged in. Because the request appears to come from a legitimate, authenticated user, the application processes it without the user's knowledge or consent.

Key Points

CSRF targets authenticated sessions - Attacks only work when the victim has an active session with the target application
Exploits automatic credential submission - Browsers automatically include cookies and authentication tokens with requests
No credential theft required - Attackers don't need to steal passwords; they leverage existing sessions
Can affect any state-changing operation - Fund transfers, password changes, email updates, and account deletions are common targets

How CSRF Attacks Work

Attack Sequence

Step	Actor	Action
1. Authentication	User	Logs into legitimate web application and receives session cookie
2. Crafting	Attacker	Creates malicious request disguised as legitimate content
3. Delivery	Attacker	Sends crafted link, image, or form to victim via email, message, or malicious site
4. Execution	User's Browser	Automatically includes authentication cookies when making the request
5. Processing	Web Application	Trusts the request because it contains valid session credentials
6. Completion	Web Application	Executes unintended action on behalf of the victim

Common Attack Vectors

Malicious links - Hidden in emails or messages that trigger requests when clicked
Embedded images - <img> tags with src pointing to action URLs
Hidden forms - Auto-submitting forms on attacker-controlled websites
Cross-origin requests - AJAX calls from malicious sites to vulnerable applications

Prevention Techniques

Anti-CSRF Tokens (Synchronizer Tokens)

The most effective defense against CSRF attacks involves generating unique, unpredictable tokens for each session or request.

Implementation approach:

Server generates a random token and associates it with the user's session
Token is embedded in forms as a hidden field or included in request headers
Server validates the token on every state-changing request
Requests without valid tokens are rejected

<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="a8f7d9e2b4c1...">
  <input type="text" name="amount">
  <button type="submit">Transfer</button>
</form>

SameSite Cookie Attribute

Modern browsers support the SameSite cookie attribute, which restricts when cookies are sent with cross-site requests.

Value	Behavior
`Strict`	Cookies only sent with same-site requests (most secure)
`Lax`	Cookies sent with top-level navigation but not embedded requests (balanced)
`None`	Cookies sent with all requests (requires `Secure` flag)

Re-authentication for Sensitive Actions

Require users to re-enter credentials before executing critical operations:

Password changes
Email address modifications
Large financial transactions
Account deletions

HTTP Referer and Origin Header Validation

Verify that requests originate from trusted sources by checking:

Referer header - Indicates the page that initiated the request
Origin header - More reliable, indicates the origin of the request

Note: Header validation should be a secondary defense, not the primary protection, as headers can be absent in legitimate scenarios.

Additional Security Measures

Custom request headers - Require headers that cross-origin requests cannot set
Double-submit cookies - Send token both as cookie and request parameter
User interaction requirements - Implement CAPTCHA for sensitive operations

Practical Example

Scenario: Banking Application Vulnerability

Alice is logged into her online banking account at bank.example.com. She has $10,000 in her account and an active session cookie.

Malorie, an attacker, sends Alice an email with the following content:

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

When Alice opens the email, her browser automatically sends a request to the banking site, including her authentication cookies. If the bank doesn't implement CSRF protection, it processes the transfer as a legitimate request from Alice, sending $5,000 to Malorie's account without Alice's knowledge.

With CSRF Protection:

The bank requires an anti-CSRF token with every transfer request. Since Malorie cannot predict or obtain Alice's token, the malicious request is rejected by the server.

Real-World Impact

CSRF vulnerabilities have been exploited in numerous high-profile attacks:

Financial fraud - Unauthorized fund transfers in banking applications
Account takeover - Email address changes leading to password reset exploitation
Social media manipulation - Unwanted posts, follows, or privacy setting changes
Router configuration changes - Modifying DNS settings on home routers
E-commerce fraud - Unauthorized purchases or shipping address modifications

Testing for CSRF Vulnerabilities

Manual Testing Checklist

Remove or modify CSRF tokens in requests and observe if they're validated
Submit requests from different origins or domains
Check if tokens are tied to user sessions
Verify token randomness and unpredictability
Test if tokens expire appropriately

Automated Tools

Burp Suite - Intercept and modify requests to test token validation
OWASP ZAP - Automated CSRF vulnerability scanning
CSRFTester - Specialized tool for CSRF detection

Best Practices

Implement defense in depth - Use multiple CSRF prevention techniques together
Apply protection to all state-changing operations - Not just obvious sensitive actions
Use framework-provided protections - Most modern frameworks include built-in CSRF defenses
Educate users - Encourage logging out of sensitive applications when finished
Regular security audits - Periodically test applications for CSRF vulnerabilities
Monitor for suspicious activity - Implement logging and alerting for unusual request patterns

Learn More