adevilinyc

CSRF protection without tokens or hidden form fields

https://blog.miguelgrinberg.com/post/csrf-protection-without-tokens-or-hidden-form-fields

CSRF Protection without Tokens or Hidden Form Fields

A couple of months ago, I received a request from a random Internet user to add CSRF protection to my little web framework Microdot, and I thought it was a fantastic idea.When I set off to do this…

Dec 22 at 5:38amWeb
Show threadowenthejumperDec 24

Right now the problem is what the author already mentions - the use of Sec-Fetch-Site (FYI, HTTP headers are case insensitive :) - is considered defense in depth in OWASP right now, not a primary protection.

Unfortunately OWASP rules the world. Not because it's the best way to protect your apps, but because the corporate overloads in infosec teams need to check the box with "Complies with OWASP Top 10"

Show threadtptacekDec 25
The OWASP Top 10 is a list of vulnerabilities, not a checklist of things you have to actually "do".
Show threadscott_wDec 25

While you’re correct, corporate security teams demand suppliers “comply with OWASP,” despite this being a nonsensical statement to anyone who’d read the website.

Unfortunately, the customer purchasing your product doesn’t know this and (naturally) trusts their own internal experts over you. Especially given all their other suppliers are more than happy to state they’re certified!

Show threadtptacekDec 25
I'm, uh, pretty familiar with the routine. I stand by what I said: you do not need any particular CSRF defense in place; you need to not have CSRF vulnerabilities. There's no OWASP checkbox-alike that requires you to have CSRF tokens, and plenty of real line-of-business apps at gigantic companies don't.
Show threadtmsbrgDec 24

I'm surprised there's no mention of the SameSite cookie attribute, I'd consider that to be the modern CSRF protection and it's easy, just a cookie flag:

https://scotthelme.co.uk/csrf-is-dead/

But I didn't know about the Sec-Fetch-Site header, good to know.

Cross-Site Request Forgery is dead!

After toiling with Cross-Site Request Forgery on the web for, well forever really, we finally have a proper solution, it's Same-Site Cookies.

Scott Helme
Show threadmiguelgrinbergDec 24
The OWASP CSRF prevention cheat sheet page does mention SameSite cookies, but they consider it defense in depth: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re....
Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series

Website with the collection of all the cheat sheets of the project.

Show threadtptacekDec 25
Because of clientside Javascript CSRF, which is not a common condition.
Show threadnchmyDec 25
Client side js is not particularly relevant to csrf.
Show threadtptacekDec 25
I mostly agree, but that's the logic OWASP uses to argue you should still be doing explicit tokens even if you're using SameSite and Sec-Fetch.
Show threadhatefulheartDec 25

I’m confused, how does this prevent a CSRF attack?

SameSite or not is inconsequential to the check a backend does for a CSRF token in the POST.

Show threadtptacekDec 25
No? The whole point of SameSite=(!none) is to prevent requests from unexpectedly carrying cookies, which is how CSRF attacks work.
Show threadlouiskottmannDec 25

This is a massive change for cache in webapp templates as it makes their rendering more stable and thus more cacheable.

A key component here is that we are trusting the user's browser to not be tampered with, as it is the browser that sets the Sec-Fetch-Site header and guarantees it has not been tampered with.

I wonder if that's a new thing ? Do we already rely on browsers being correct in their implementation for something equally fundamental ?

Show threadtptacekDec 25
The entire web security model assumes we can trust browsers to implement web security policies!
Show threadlouiskottmannDec 25
I appreciate that, but in the case of TLS or CSRF tokens the server is not blindly trusting the browser in the way Sec-Fetch-Site makes it.
Show threadtptacekDec 25
Sure it is. The same-origin rule that holds the whole web security model together is entirely a property of browser behavior.