csrf not all defenses are created equal
TRANSCRIPT
PowerPoint Presentation
CSRF: Not All Defenses Are Created Equal
Ari Elias-BachrachDefensium llc
November 2013
This Talk is a Review of Current Defensive Options
Or the long tail?
Is your application one of the 80%
This Talk Will Cover CSRF Defenses and Their Side Effects
What is CSRF
General (high level) fixes
Code level defenses
Server level defenses
CSRF occurs when an attacker tricks a user's browser into performing an action on a website
Normally, Browser's Form Submissions are Straightforward and Predictable
GET /submitpage?amount=100.00&dest=12345Server: server.com
POST /submitpageServer: server.com
amount=100.00&dest=12345
If action was a POST
If action was a GET
Normally, Browser's Form Submissions are Straightforward and Predictable
If you can predict all the parameters for an action, you can fake it
To Fake a GET
http://server.com/submitpage?amount=100.00&dest=12345
http://webmail.com/sendEmail?dest=boss@work&subj=resignation
If you can predict all the parameters for an action, you can fake it
To Fake a POST
document.evil.submit()
1. User navigates to website which attacker has some control over
2. User's browser tries to load content from site
3. Content performs action at a legitimate site
Anatomy of an Attack
Anatomy of an Attack
Malicious code
Legitimate site
Session cookie
In 2008, A CSRF flaw Was Used to Attack Cable Modems
Found a CSRF flaw in ADSL modems used by a Brazilian ISP
Used it to Change DNS settings
Sent users to malicious websites that looked like www.google.br
High Level Defenses (Design Patterns)
There are Four Design Patterns Which are Used
Synchronizer Token Pattern
Double Submit Cookies
Challenge Response
Check Referrer Header
Make at least one parameter unpredictable
Upon submission, check to ensure the submitted value matches the generated value
Primary Defense is the Synchronizer Token Pattern The most common defense
Things to look out for - How are tokens remembered? - Completeness of coverage
Primary Defense is the Synchronizer Token Pattern The most common defense
Generate a random value, store it in two places: 1 a cookie 2 a hidden form field
Upon submission, check to see if they match
Second Defensive Option is Double Submit CookiesThis option used less often, but useful for things like REST
abc123
abc123
abc123
=abc123
Things to look out for: - Do not use the Session ID for this purpose!
Second Defensive Option is Double Submit CookiesThis option used less often, but useful for things like REST
abc123
abc123
abc123
=abc123
A Third Option is Any Form of Challenge Response System Rarely Used Exclusively for CSRF Defense
A Third Option is Any Form of Challenge Response System Rarely Used Exclusively for CSRF Defense
A Third Option is Any Form of Challenge Response System Rarely Used Exclusively for CSRF Defense
A Third Option is Any Form of Challenge Response System Rarely Used Exclusively for CSRF Defense
A Third Option is Any Form of Challenge Response System Rarely Used Exclusively for CSRF Defense
Things to look out for: - User impact
A Fourth Option is to Check the Referrer Header I Have Never Seen This Implemented
GET /services/transfer.jsp HTTP/1.1Host: mybank.comUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0Accept: */*Accept-Language: en-US,en;q=0.5Referer: http://t.co/xblu14l6vLCookie: JSESSIONID=007f0100547a514c54060044;
A Fourth Option is to Check the Referrer Header I Have Never Seen This Implemented
Things to look out for: - Potential impact on other things which may modify the referer header
Actually Implementing These Patterns is Where it Gets Fun and Complicated
Code FixesServer Fixes
We Will Show Five Common Software Libraries That Can Be Used To Do CSRF Defense
ViewState User Keys (.net)
AntiForgeryToken (.net MVC)
AntiCSRF (.net)
CSRFGuard (Java, PHP port is in progress)
HDIV (Java)
.net can add CSRF protections to the ViewState
Viewstate is meant to maintain a form's state on postbacks
Page.aspx
Page.aspx
.net can add CSRF protections to the ViewState
Adding the session ID to the view state makes it unpredictable
sessionID
.net can add CSRF protections to the ViewState
Add to OnInit for all pages or once to base class protected override OnInit(EventArgs e) {base.OnInit(e); if (User.Identity.IsAuthenticated) ViewStateUserKey = Session.SessionID; }
.net can add CSRF protections to the ViewState
Viewstate User Keys was designed to protect against 1 click attacks, which are a subset of CSRF attacks
Page.aspx
Other.aspx
Other.aspx
Only protects postbacks - Won't protect posts to other pages
.net MVC Applications Can Use AntiForgeryToken
What about .net MVC?
AntiForgeryToken - Part of the HtmlHelper class
.net MVC Applications Can Use AntiForgeryToken
.net MVC Applications Can Use AntiForgeryToken
Validate the token in the controller
[ValidateAntiForgeryToken]public ActionResult FunctionToProtect(){ // this is now run only if the token is valid}
.net MVC Applications Can Use AntiForgeryToken
By Default, will only work for POSTNot a problem if GET is idempotent
Can be hacked to work, google for details
Request.Params versus Request.Form param does GET r POST, form does only POST
.net MVC Applications Can Use AntiForgeryToken
Obvious problem: the forgetful programmer - must add to every controller and function that needs to be protected
Anticsrf for .net implements the double submit cookies pattern
Anticsrf
- For .net- Has no other requirements (like viewstate enabled, MVC, etc.)- Open source- Developed in C#
Available from http://anticsrf.codeplex.com/
Anticsrf for .net implements the double submit cookies pattern
Generates string using Guid.NewGuid()
Cookie: __CSRFCOOKIE=a22b81af-74f0-45ee-b2fd-1ead5f31f1c2;
in POST
__CSRFTOKEN=a22b81af-74f0-45ee-b2fd-1ead5f31f1c2
abc123
abc123
abc123
=abc123
Anticsrf for .net implements the double submit cookies pattern
Can be used in a .net web appNew Token for each sessionOnly protects POST (not a problem if GET is idempotent) - Won't work for Rest (unless you hack it)
abc123
abc123
abc123
=abc123
CSRFGuard Implements the Synchronizer Token Pattern and Makes a New Token For Each Session
Made By OWASP (open source, BSD license)
Java currently, PHP and .net port in progress
Keeps one token per session, stored in the session - exposure of token compromises entire session
CSRFGuard Implements the Synchronizer Token Pattern and Makes a New Token For Each Session
Modifies existing GET and POST requestsKeeps one token per session, stored in the session - exposure of token compromises entire session
link=nonce1
action=nonce1
CSRFGuard Can Also be Configured to Generate a New Token For Each Page
Each link or action would get a unique token valueStored in session
Feature is still experimental
link=page?nonce1
action=page2?nonce2
CSRFGuard Can Also be Configured to Generate a New Token For Each Page
Also supports AJAX
Sets the token value in an HTTP header
HDIV Uses Tokens With a Queue Based Expiry
link=page?nonce1
action=page2?nonce2
HDIV is a Java library that provides several security functions, including CSRF defense using the Synchronizer Token Pattern.
The queue includes all generated tokens (could be dozens per page).
These Five Libraries All Have Different Approaches To CSRF Defense
ViewState User Keys (.net)
AntiForgeryToken (.net MVC)
AntiCSRF (.net)
Synchronizer Token Pattern - only postbacks
Synchronizer Token Pattern - needs lots of code changes
Double Submit Cookies
These Five Libraries All Have Different Approaches To CSRF Defense
CSRFGuard (Java)
HDIV
Synchronizer Token Pattern - can be done per session or page
Synchronizer Token Pattern - per link/action - queue based expiry
We Can Also Implement CSRF Protection on the Server
Changing code on existing applications is hard
What if we asked the server to do CSRF protection
Tomcat 7 Includes a CSRF Prevention Filter
Generates a new UUID for each page loaded - default generator is java.security.SecureRandom)
Protects GET and POST - modifies links and form actions
Stores the last n UUIDs in the session - default for n is 5
http://server/page?org.apache.catalina.filters.CSRF_NONCE=31ACB2CA0A9...
link=nonce1
Tomcat's CSRF Prevention Filter Can Cause Usability Issues for User's With Multiple Browser Tabs Open
User opens a second tab (same session, same cookies, etc.)
Makes n mouse clicks (default n is 5)
Original tab is now broken
nonce2nonce3nonce4nonce5nonce6
nonce1
F5's ASM Can Insert a Token in All Links and Forms to Implement the Synchronizer Token Pattern
F5's ASM Can Insert a Token in All Links and Forms to Implement the Synchronizer Token Pattern
Will protect all GET and POST requests
Token are generated per session, and have an expiry time (configurable from 1-99999 seconds). Default is 600 seconds
Obvious problem of timeouts
Imperva SecureSphere Can Detect CSRF Attacks by Checking the Referrer Header
SecureSphere (Imperva's WAF) can alert and block when the referrer header of a request is from an external site
GET /services/transfer.jsp HTTP/1.1Host: mybank.comUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0Accept-Language: en-US,en;q=0.5Referer: http://t.co/xblu14l6vLCookie: JSESSIONID=007f0100547a514c54060044;
Imperva SecureSphere Can Detect CSRF Attacks by Checking the Referrer Header
The referrer header is not respected in all situations
Bookmarks, links from external sites, and plugins that stop or tamper with the referrer header can all cause false positives
All Three Of The Servers We Looked At Do CSRF Defense Differently
Synchronizer Token Pattern - Queue based expiry
Synchronizer Token Pattern - Time based expiry
Check Referrer Header - Is intended for detection, not prevention
CSRF Token Names Can Reveal What Library You Are Using
CSRF Token Names Can Reveal What Library You Are Using
CSRF Token Names Can Reveal What Library You Are Using
Tomcat
513 results
CSRFGuard
126,000 results
CSRF Token Names Can Reveal What Library You Are Using
Almost all of the solutions we've mentioned that use tokens allow you to customize the name of the token
Some require you to edit source code to do it...
A single XSS flaw makes all of these CSRF defenses useless
There are numerous ways for a script to access the CSRF token value
document.cookiedocument.getElementByID('csrftoken')document.forms[0].elements[0]
Protecting GET Requests Comes At A Cost
GET /page HTTP/1.1Host: othersite.comReferer: http://mysite.com/page?CSRF_TOKEN=1ba5690d4ea45fbab3
CSRF tokens can be leaked through the referer header, and can be reused if they're still valid
We Have Seen Seven Widely Used Implementations of CSRF Defense
Know your defenses which solution you select will depend on your application
How many of these solutions were perfect?
Security is rarely 'plug n play'
We Have Seen Seven Widely Used Implementations of CSRF Defense
Know your defenses which solution you select will depend on your application
Environment and language used
Whether this is a new app or a retrofit of an old one
Idempotence
Potential user impact of some solutions
CSRF: Not All Defenses Are Created Equal
Ari Elias-Bachrach
[email protected]@angelofsecurity
Defensium llchttp://www.defensium.com
CSRF: Not All Defenses Are Created Equal