CSRF: not all defenses are created equal

Presented at AppSec USA 2013, Nov. 21, 2013, 3 p.m. (50 minutes)

CSRF is an often misunderstood vulnerability. The standard way to protect against it is by implementing the singleton token pattern. This is usually done in the framework and not by the individual developer. For example .net applications can use the antiforgerytoken (for MVC applications) or viewstateuserkey. Tomcat web server and F5 load balancers also now include CSRF prevention filters. OWASP of course has the CSRF guard. All of these solutions though are slightly different and can lead to different side effects, some of which are little understood and poorly documented. Some side effects have even caused worse security problems (namely revealing the session cookie) while trying to defend against CSRF. In this talk I will introduce CSRF and the basic defenses against it. Then I will go through all of the various major solutions mentioned above and describe how they implement the general solution and the positives and negatives of each implementation.


  • Ari Elias-Bachrach - independant consultant - Defensium LLC
    In the course of implementing CSRF defenses in the extremely broad (over 3000 web applications) and diverse environment that is the NIH, I have found that not all CSRF defenses are created equal. A lot of research, experimentation, and conversations with vendors and developers have yielded an understanding of the wide variety of csrf defenses and their tradeoffs, which I would like to share with the industry at large.


Similar Presentations: