Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSRF protection without tokens or hidden form fields

blog.miguelgrinberg.com

Post reply on HN
Print view View original

31–40 of 116 posts

Re: CSRF protection without tokens or hidden form fields

#31

Post by hn_throwaway_99 »

nhumrich wrote: post #23
tmsbrg wrote: post #4

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.

This is "not allowing cross site at all" so, technically it's not "request forgery" protection. Yes, this is very semantic, but, CSRF is a vulnerability introduced by enabling CS and CORS. So, technically, same-site cookies are not "protection" against CSRF.

I don't understand your distinction at all. I may not quite grok your meaning here, but CORS is usually discussed in the context of allowing cross-origin AJAX calls.

But cross origin form posts are and have always been permitted, and are the main route by which CSRF vulnerabilities arise. Nothing on the client or server needs to be enabled to allow these form posts.

Furthermore, the approach detailed in the article simply has the server block requests if they are cross site/origin requests, so I'm not sure what the semantic difference is.

Re: CSRF protection without tokens or hidden form fields

#32

Post by louiskottmann »

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 ?

Re: CSRF protection without tokens or hidden form fields

#33

Post by hatefulheart »

tmsbrg wrote: post #4

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.

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.

Re: CSRF protection without tokens or hidden form fields

#34

Post by hn_throwaway_99 »

miguelgrinberg wrote: post #5
tmsbrg wrote: post #4

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.

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... .

I don't understand the potential vulnerabilities listed at the linked section here: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc...

They give 2 reasons why SameSite cookies are only considered defense in depth:

----

> Lax enforcement provides reasonable defense in depth against CSRF attacks that rely on unsafe HTTP methods (like "POST"), but does not offer a robust defense against CSRF as a general category of attack:

> 1. Attackers can still pop up new windows or trigger top-level navigations in order to create a "same-site" request (as described in section 2.1), which is only a speedbump along the road to exploitation.

> 2. Features like "" [prerendering] can be exploited to create "same-site" requests without the risk of user detection.

> When possible, developers should use a session management mechanism such as that described in Section 8.8.2 to mitigate the risk of CSRF more completely.

----

But that doesn't make any sense to me. I think "the robust solution" should be to just be sure that you're only performing potential sensitive actions on POST or other mutable method requests, and always setting the SameSite attribute. If that is true, there is absolutely no vulnerability if the user is using a browser from the past seven years or so. The 2 points noted in the above section would only lead to a vulnerability if you're performing a sensitive state-changing action on a GET. So rather than tell developers to implement a complicated "session management mechanism", it seems like it would make a lot more sense to just say don't perform sensitive state changes on a GET.

Am I missing something here? Do I not understand the potential attack vectors laid out in the 2 bullet points?

Re: CSRF protection without tokens or hidden form fields

#35

Post by tptacek »

louiskottmann wrote: post #32

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 so…

The entire web security model assumes we can trust browsers to implement web security policies!

Re: CSRF protection without tokens or hidden form fields

#36

Post by tptacek »

hatefulheart wrote: post #33
tmsbrg wrote: post #4

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.

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.

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

Re: CSRF protection without tokens or hidden form fields

#37

Post by est »

amluto wrote: post #26
est wrote: post #18

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

Or sending Content-Security-Policy: script-src 'none' for everything that isn’t intended to be a document. Or both. IMO it’s too bad that suborigins never landed. It would be nice if Discord’s mintlify route could set something like Suborigin: mintlify, thus limiting the blast radius to the mintlify section.

maybe adding a dedicated cookie for that specific path?

Re: CSRF protection without tokens or hidden form fields

#38

Post by [deleted] »

owenthejumper wrote: post #2

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"

[deleted]

Re: CSRF protection without tokens or hidden form fields

#39

Post by louiskottmann »

tptacek wrote: post #35
louiskottmann wrote: post #32

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 so…

The entire web security model assumes we can trust browsers to implement web security policies!

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.

Re: CSRF protection without tokens or hidden form fields

#40

Post by thomascountz »

8n4vidtmkvmk wrote: post #30
owenthejumper wrote: post #2

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"

Since when are they case sensitive? https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... says otherwise. It's possible for a server to treat them as case sensitive, but that seems like a bad idea.

+1

HTTP/2, headers are not unique if they only differ by casing, but they must be encoded as lowercase.

   Just as in HTTP/1.x, header field names are strings of ASCII characters that are compared in a case-insensitive fashion. However, header field names MUST be converted to lowercase prior to their encoding in HTTP/2.  A request or response containing uppercase header field names MUST be treated as malformed (Section 8.1.2.6).[1]
HTTP/1.X, headers are insensitive to casing for reasons of comparison and encoding.

   Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.[2]
So, if Sec-Fetch-Site is sensitive at all, it would be sec-fetch-site when sending via HTTP/2 and you're responsive for encoding/decoding.

[1]: https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2

[2]: https://datatracker.ietf.org/doc/html/rfc2616#section-4.2

Post reply on HN