The Forged Letter Analogy
Imagine someone sends a letter to your bank:
- Letter says: "Transfer $1000 to Eve"
- Signed with your name (forged!)
- Bank thinks it's really you
CSRF makes your browser send requests you didn't intend. Attackers exploit your logged-in session.
What Is CSRF?
You're logged into your bank (cookies stored).
You visit a malicious website.
That site has hidden code that tells YOUR browser:
"Send a request to bank.com to transfer money"
Your browser:
- Follows the instruction
- Attaches YOUR bank cookies
- Bank sees YOUR session
- Bank performs the transfer
You didn't intentionally click "Transfer".
How CSRF Works
The Attack Flow
1. Victim logs into bank.com
Browser stores session cookie
2. Victim visits evil.com (or clicks malicious link)
3. evil.com contains:
<img src="bank.com/transfer?to=attacker&amount=1000">
or hidden form that auto-submits
4. Victim's browser loads the image/submits form
Sends bank.com cookies automatically!
5. Bank sees valid session, performs transfer
Victim lost $1000!
Why It Works
Browsers automatically attach cookies to requests.
Bank can't tell:
- User intentionally clicked button
- vs. Request came from malicious site
Both look identical to the server!
CSRF Prevention
1. CSRF Tokens (Most Common)
Server generates random token per session:
csrf_token = "a7d9f3k2..."
Included in forms:
<input type="hidden" name="csrf" value="a7d9f3k2...">
On submit, server checks:
Does token match what we issued?
If not → Reject!
Attacker can't guess/obtain the token.
2. SameSite Cookies
Set-Cookie: session=abc123; SameSite=Strict
SameSite=Strict:
Cookie is typically sent for same-site requests.
Cross-site request → cookie often isn't included → attack may fail.
SameSite=Lax:
Cookie sent for top-level navigations.
Blocks most CSRF but allows some legitimate uses.
3. Check Origin/Referer Headers
Server checks:
Origin: https://bank.com âś“
Origin: https://evil.com âś— Reject!
Not 100% reliable (headers can be stripped).
Use with CSRF tokens.
4. Require Re-authentication
Sensitive actions (password change, transfers):
Ask for password/2FA again.
Attacker doesn't know your password.
Attack Examples
Hidden Image
<img src="https://bank.com/transfer?to=attacker&amount=500" width="0" height="0">
Invisible image, browser loads it.
GET request sent to bank with your cookies.
Auto-Submit Form
<form action="https://bank.com/transfer" method="POST">
<input name="to" value="attacker">
<input name="amount" value="500">
</form>
<script>document.forms[0].submit();</script>
Form submits instantly on page load.
Link Click
<a href="https://bank.com/transfer?to=attacker&amount=500">
Click here for free money!
</a>
User clicks, request sent with their cookies.
CSRF vs XSS
| Aspect | CSRF | XSS |
|---|---|---|
| Attack method | Force user's browser to make request | Inject malicious script |
| User action | Visits attacker's site | Visits vulnerable site |
| Attacker gets | Actions on behalf of user | User's cookies/data |
| Prevention | CSRF tokens, SameSite | Input sanitization, CSP |
XSS can bypass CSRF protections!
If attacker can run scripts, they can read CSRF tokens.
Fix XSS first!
Common Practices
1. Use CSRF Tokens for All State-Changing Requests
POST, PUT, DELETE → Need CSRF token
GET → Should be read-only (no side effects)
Avoid modifying state with GET requests.
2. Enable SameSite Cookies
Default in modern browsers.
Explicitly set for older browser support.
Set-Cookie: session=abc; SameSite=Lax; HTTPS-only; HttpOnly
3. Don't Use GET for Sensitive Actions
Bad: GET /delete-account?confirm=true
Good: POST /delete-account (with CSRF token)
GET requests are too easy to forge.
Common Mistakes
1. CSRF Token in Cookie Alone
Token in cookie = useless!
Attacker's request includes all cookies.
Token should be:
- In form body (hidden field)
- OR in request header
- AND validated against server-stored value
2. Predictable Tokens
Token = user_id + timestamp → Predictable!
Use: Cryptographically random tokens.
3. GET Requests with Side Effects
GET /unsubscribe?user=123
Image tag in email auto-unsubscribes user!
Use POST for any action.
FAQ
Q: Does HTTPS prevent CSRF?
No! HTTPS encrypts data but doesn't prevent forged requests.
Q: Are APIs vulnerable to CSRF?
If they use cookies for auth, yes. Token-based auth (token in an Authorization header) is naturally CSRF-resistant.
Q: Does SameSite=Strict break anything?
It can break legitimate cross-site flows. Lax is usually a good balance.
Q: Is CSRF still relevant?
Yes! SameSite helps, but not all browsers/cases are covered. Use tokens too.
Summary
CSRF tricks browsers into making requests using your authenticated session, exploiting automatic cookie attachment.
Key Takeaways:
- Browser sends cookies automatically with requests
- Attacker exploits YOUR session from THEIR site
- Use CSRF tokens for state-changing requests
- Set SameSite=Lax or Strict on cookies
- Avoid using GET for sensitive actions
- XSS can bypass CSRF protections → Fix XSS too!
CSRF is sneaky - your browser works against you when you visit a malicious site!
Related Concepts
Leave a Comment
Comments (0)
Be the first to comment on this concept.
Comments are approved automatically.