Modern Approaches to Web Security: Stateless CSRF Protection Explained

In today’s evolving threat landscape, robust web security practices are paramount to safeguarding applications and user data. This talk delves into modern approaches to web security, with a spotlight on stateless CSRF (Cross-Site Request Forgery) protection. Drawing from recent advancements in Symfony, we’ll explore how to secure web applications without relying on traditional session storage.

Transcript

1. Modern Approaches to Web Security: Stateless CSRF Protection Explained @nicolasgrekas
2. CSRF Introduction Cross-Site Request Forgery
3. Social Engineering User is logged on legitimate bank.com account User opens adversary bang.com without noticing
4. <!-- on bang.com --> <form action="https://bank.com/transfer" method="post"> <input name="amount" value="1000"> <input name="from" value=" "> <input name="to" value=" "> </form>
5. bank.com Session cookie sent to bank.com Transfer accepted
6. The Ideal CSRF Protection is Standalone Robust Transparent Cacheable and mandates no JS
7. Check the "Origin" header
8. RFC 6454 Origin: https://bang.com/ Browsers send them automatically That's all what bank.com ​needs
10. RFC 6454 Cacheable, mandates no JS Requires the app to know its own origin => trusted proxy headers FTW / RTFM Use CORS headers for cross-domain needs
11. A browser bug could compromise security protections. Mixing many strategies adds additional layers of defense and gives us more control over security of the application.
12. CSRF Protection OWASP Cheat Sheet Series
13. TL;DR Stateful apps should use session tokens Stateless apps should use double-submit cookies Implement defense-in-depth mitigations Ask some user credentials for sensitive operations Do not use GET requests for state changing operations, or protect them against CSRF
14. Cross-Site Scripting (XSS) or a Man-In-The-Middle (MITM) can defeat all CSRF mitigations!
15. <!-- on bank.com --> <form action="https://bank.com/transfer" method="post"> <input name="amount" value="1000"> <input name="from" value=" "> <input name="to" value=" "> <input name="token" value=" " type="hidden"> </form>
16. <!-- on bang.com --> <form action="https://bank.com/transfer" method="post"> <input name="amount" value="1000"> <input name="from" value=" "> <input name="to" value=" "> <input name="token" value=" " type="hidden"> </form>
17. Session Tokens Caveats Session cookie means page is not-cacheable (Not even login pages) Tokens are a target for attacks Regeneration mandatory at key steps (logins, expiry) Vulnerable to BREACH ​attacks Token rotation means usability concerns (e.g. broken form sumissions or "Back" buttons)
18. Session Tokens Improvements Session cookie means page is not-cacheable window.fetch() to populate the token (PR #54705) Tokens are a target for attacks Regeneration mandatory at key steps (logins, expiry) Always-random part against BREACH ​attacks Token rotation means usability concerns
19. Double-Submit Cookie Pattern No server-side state
20. <!-- on bank.com --> <form action="https://bank.com/transfer" method="post" onsubmit=" let token = window.crypto.getRandomValues(/*...*/); document.cookie = 'Csrf-Token=' + token; this.token.value = token; "> <input name="token" type="hidden"> </form>
21. Naive? Discouraged? Cookie fixation Subdomains handling "secure" cookies set from MITMed HTTP => Generate a new token every time in JS
22. Defense In Depth Use HSTS Use "SameSite" attribute for the session cookie Prefix cookie names with "__Host-" Use a custom HTTP header instead of cookie Check the "Origin" header
23. The Ideal CSRF Protection is leveraging Symfony
29. Origin Check the Origin header Covers 97% of end users Cacheable No JS
30. Cookie Check the double-submitted Cookie header Implements all security-in-depth mitigations Safe to race-conditions Cacheable Requires JS – snippet shipped as a UX recipe
31. Header Check the double-submitted csrf-token header Not enabled by default Compatible with cookie-clearing reverse proxies Cacheable Requires JS – snippet shipped as a UX recipe
32. Session Check the previously successful strategies Still stateless because opportunistic
34. Can you break it?
35. Be Happy with Symfony! @nicolasgrekas