CSRF: not all defenses are created equal presented at AppSec USA 2013

by Ari Elias-bachrach,

Summary : 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: Ari is a CISSP and CEH. He has a BS in computer science from Washington University in St. Louis, and a MS in computer science with a focus on information security from The George Washington University. Previously he worked for the federal government, followed by a stint in the private sector as a consultant performing external penetration testing and web application reviews. Now he works as an in-house information security engineer focusing on web applications.