logoalt Hacker News

CSRF protection without tokens or hidden form fields

146 pointsby adevilinyclast Monday at 5:38 AM37 commentsview on HN

Comments

owenthejumperyesterday at 10:47 PM

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 5 replies
tmsbrgyesterday at 11:02 PM

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.

show 4 replies
rvnxtoday at 12:36 AM

If you want, “SameSite=Strict” may also be helpful and is supported on “all” browsers so it is reasonable to use it (but like you did, adding server validation is always a +).

https://caniuse.com/mdn-http_headers_set-cookie_samesite_str...

This checks Scheme, Port and Origin to decide whether the request should be allowed or not.

show 2 replies
esttoday at 2:22 AM

reminds me of something similar

https://news.ycombinator.com/item?id=46321651

e.g. serve .svg only when "Sec-Fetch-Dest: image" header is present. This will stop scripts

show 1 reply
louiskottmanntoday at 5:12 AM

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 1 reply
altmindtoday at 12:38 AM

Are there any approaches to csrf tokens that don't require storing issued tokens on server-side?

show 3 replies
shermantanktopyesterday at 11:48 PM

Am I missing something? The suggested protection helps with XSS flavors of CSRF but not crafted payloads that come from scripts which have freedom to fake all headers. At that point you also need an oauth/jwt type cookie passed over a private channel (TLS) to trust the input. Which is true for any sane web app, but still…

show 3 replies