CSRF: not all defenses are created equal
Talkat AppSec California 2014 · on Tuesday, 2014-01-28· at 09:30· Track 2, Annenberg Community Beach House, East Pacific Coast Highway·
summary
Compares concrete defenses and shows which actually break or preserve functionality: synchronizer token pattern versus double submit cookies versus referrer checks and captchas, with real tools named (antiforgerytoken, viewstateuserkey, Tomcat filter, F5 ASM, OWASP CSRF Guard, Imperva Securesphere, Hdiv). Claims most solutions work about 80% of cases, points out Tomcat keeps only five tokens by default, F5 uses a timebased expiry (≈10 minutes), and referrer checks cause many false positives so they rarely run blocking.
AI-written summary · about
chapters (11)
- 0:00Intro
- 3:51If you can predict all the parameters for an action, you can fake it
- 6:50High Level Defenses (Design Patterns)
- 7:41Primary Defense is the Synchronizer Token Pattern
- 9:07Second Defensive Option is Double Submit Cookies This option used less often, but useful for things like REST
- 12:29A Third Option is Any Form of Challenge Response System Rarely Used Exclusively for CSRF Defense
- 23:37CSRFGuard Implements the Synchronizer Token Pattern and Makes a New Token For Each Session
- 30:47Tomcat 7 Includes a CSRF Prevention Filter
- 33:19F5's ASM Can Insert a Token in All Links and Forms to Implement the Synchronizer Token Pattern
- 35:07Imperva Secure Sphere Can Detect CSRF Attacks by Checking the Referrer Header
- 39:45CSRF Token Names Can Reveal What Library You Are Using
related talks
35mFlagship Projects: CSRFGuard
36mCSRF Vulnerabilities Are Still Relevant
40mModern Web Application Defense with OWASP Tools
47mD2T2 - Defense-in-Depth Techniques for Modern Web Apps
47mKeynote: Request Forgery on the Web - SSRF, CSRF and Clickjacking
54mEverything You Wanted to Know About Client side CSRF But Were Afraid to Ask
32mSecurity-First Web Apps
31mXSS, CSRF, CSP, JWT, Wtf? Idk ¯\_(ツ)_/¯