What CSRF Is Not
-
A direct, server-targeting attack
e.g. SQL Injection, Persistent XSS, Authentication Bypass
- Uncommon :(
- Well understood :(
-
Someone else's problem
CSRF Is
- A browser/session targeting attack
- HIGHLY variable in terms of impact
- Likely a problem if your app:
- Has forms
- Uses sessions
- “... an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated.” (OWASP Wiki)
Web Apps 101
A web form allows two distinct actions:
📄 View
⚙ Submit
Each of these can be accessed independently
Simple Web App v1
- You create a form which allows you to add new accounts.
- It's important that not just anyone be allowed to use this form. So, we'll tie this in to our log in page.
- Now, in order to view or submit the form, you'll first need to log in.
Simple Web App v2
- In order for this to work, the application keeps track of who you're logged in as in a session, which persists between requests.
- When you attempts to submit the form, the app looks at your session to figure out who you are and if you are allowed to add users.
Auth Bypass Attack
- Attempting to circumvent these restrictions, a bad guy makes their own copy userForm, which will send submissions to your AddUser.
- Fortunately, you built this correctly. AddUser refuses the submission, as the bad guy does not have the required privileges within their session.
- But this guy is persistent...
CSRF Attack
- The bad guy modifies their form. They set default field values, make the whole form invisible, and change the form to auto submit on page load.
- He then tricks you into visiting their bad copy of the form.
- The submission is accepted and your legitimate session is used.
You might be thinking:
Just don't go to malicious sites
- Phishing → Don’t click on links in suspicious messages
- Spear Phishing → Check links for legit looking URLs
- Malvertising → And don’t visit sites with third-party advertising
- Compromised Sites / Watering Hole Attacks → And don’t visit any site that could have been compromised
- Malicious WiFi / DNS Hijacking → Don't use HTTP
QED: Don't Use The Web
Alternatively:
- Better User Awareness
- Better Browser Security
- Better Application Security
(especially CSRF, XSS, & ClickJacking defenses)
Solutions
- Synchronizer Tokens
- Verify Referer Header
- CAPTCHAs
- Custom HTTP Headers (for AJAX requests)
Defense Demo
via OWASP CSRFGuard