speaker: Ari Elias-Bachrach
Overview
- Most defenses work 80% of the time. Does your app fall into the 80%?
- CSRF sometimes pronounced c-surf
- CSRF attack uses browser to perform action without user consent
- Vulnerable if all params predictable. Then can put url in image tag. Or use JavaScript to submit (need for post)
- If have multiple tabs or haven’t logged out, your browser thinks authenticated session so can still perform actions.
Patterns
- Synchronizer token – most common alternative – use a csrf token then have server make sure gets same random value back. Watch how token is remembered and completeness of coverage
- Double submit cookies – Makes sure cookie and hidden field match. Useful for REST. Do not use session iD for this purpose. Session ID is in the GET request; not secrete
- Challenge response – CAPTCHAs or reauthentication – do protect against CSRF but usually used for other things. Watch user impact.Never seen for CSRF primarily
- Check the referrer header – the referrer should be your site not another site like twitter. You don’t perform action on first visit to the site. Watch side effects. Never seen for CSRF primarily.
Code level
(.net) ViewState
Submitted state on all postbacks. Useful for wizards. Add session id to view state for token. Now your view state is unpredictable. Works fine if only use postbacks. If sometimes actions go to other pages, won’t work.
(.net) AntiForgery token
Put Html.AntiForgeryToken() as first scriptlet in form. And add [ValidateAntiForgeryToken] before each action. Problem is by default this only works for POST by default. People have hacked it. If your application is properly designed, GET is idempotent anyway. The worse problem is the “forgetful programmer issue”. A developer can forget to add it to every form. [I wrote a unit test for this problem in Java]
(.net) AntiCsrf
Implements double submit cookies pattern. Only supports POSTS.
(Java) CsrfGuard
PHP and .NET versions in progress. Keeps on token per session by default and uses synchronizer token pattern. Problem is that exposure of token jeopardizes whole session to CSRF. Experimental option to per link/action token. Modifies get and post requests. Supports AJAX via a HTTP header. May mess up links if use funky URLs. [you shouldn’t be using GETs. grumble. It’s not that hard to change GET to POST]
(Java) HDIV – HTTP Data Integrity Validator
Uses synchronizer tokenizer pattern. Session by default. Experimental optional for link/action tokens as well. Queue based expriy. Set queue size accordingly.
Server level
Tomcat
Tomcat 7 generates UUID for each page loaded. Protects GET and POST. Runs as a filter. Don’t have to change app at all. Helpful for an old app that nobody knows about. [seems risky to me. apps have funky javascript, get vs post, etc. Oh good. Jim Manico called out that it can break your app.]
F5 (Load Balancer) ASM
Same ideas as Tomat except it has less visiblity into your session. Can have token expire based on time since can’t go by session expiration. Defaults to 10 minutes.
Imperia SecureSphere
Checks referrer header isn’t from an external site. Can see false positives. Browser plugins can tamper with referrer. Browser won’t include referrer error from SSL. More useful for detecting than preventing. There are plugins that create random referrers so would have to turn off that plugin to use your site. Also, wouldn’t stop stored XSS for CSRF attack.
Other problems
- CSRF token can reveal which library you are using. If you have an uncovered vulnerability, this could be revealed
- If you have ANY XSS vulnerability in your site (even on another page), you are not protected against CSRF
- Protecting GET pages comes at a cost [I’m glad he finally mentioned this]
My take
CSRF isn’t new to me. See what we did at CodeRanch. I think it is an important topic though and it was interesting to see about other solutions. The speaker was very thorough assuming no knowledge and covering more advanced topics.