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

51–60 of 116 posts

Re: CSRF protection without tokens or hidden form fields

#51

Post by nchmy »

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…

It's a shame you talked about browser tampering, since better caching is indeed a benefit of fetch metadata headers.

Re: CSRF protection without tokens or hidden form fields

#52

Post by tptacek »

nchmy wrote: post #48
tptacek wrote: post #29

Earlier quoted context omitted.

Because of clientside Javascript CSRF, which is not a common condition.

Client side js is not particularly relevant to csrf.

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.

Re: CSRF protection without tokens or hidden form fields

#53

Post by vasco »

> One option is to reject all requests that do not have the Sec-Fetch-Site header. This keeps everyone secure, but of course, there's going to be some unhappy users of old devices that will not be able to use your application. Plus, this would also reject HTTP clients that are not browsers. If this is not a problem for your use case, then great, but it isn't a good solution overall.

If my client is not a browser surely I can set whatever headers I want? Including setting it to same-origin?

Re: CSRF protection without tokens or hidden form fields

#54

Post by amluto »

est wrote: post #37
amluto wrote: post #26

Earlier quoted context omitted.

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?

HTTP-only cookies ought to work fine for this.

I imagine there’s a fair amount of complexity that would need to be worked out, mostly because the browser doesn’t know the suborigin at the time it makes a request. So Sec-Fetch-Site and all the usual CORS logic would not be able to respect suborigins unless there was a pre-flight check for the browser to learn the suborigin. But this doesn’t seem insurmountable: a server using suborigins would know that request headers are sent as if the request were aimed at the primary origin, and there could be some CORS extensions to handle the case where the originating document has a suborigin.

Re: CSRF protection without tokens or hidden form fields

#55

Post by hn_throwaway_99 »

eli wrote: post #49
paulryanrogers wrote: post #25

Earlier quoted context omitted.

Unsubscribe often need to be GET, or at least start as GET

list-unsubscribe header sends a POST. Probably makes more sense to just use a token from an email anyway.

The way the list-unsubscribe header works, it essentially must use a token when one click unsubscribe (i.e when the List-Unsubscribe-Post: List-Unsubscribe=One-Click header is also passed) is used, and since GMail has required one click unsubscribe for nearly 2 years now, my guess is all bulk mail senders support this. Relevant section from the one click unsubscribe RFC:

> The URI in the List-Unsubscribe header MUST contain enough information to identify the mail recipient and the list from which the recipient is to be removed, so that the unsubscription process can complete automatically. Since there is no provision for extra POST arguments, any information about the message or recipient is encoded in the URI. In particular, one-click has no way to ask the user what address or from what list the user wishes to unsubscribe.

> The POST request MUST NOT include cookies, HTTP authorization, or any other context information. The unsubscribe operation is logically unrelated to any previous web activity, and context information could inappropriately link the unsubscribe to previous activity.

> The URI SHOULD include an opaque identifier or another hard-to-forge component in addition to, or instead of, the plaintext names of the list and the subscriber. The server handling the unsubscription SHOULD verify that the opaque or hard-to-forge component is valid. This will deter attacks in which a malicious party sends spam with List-Unsubscribe links for a victim list, with the intention of causing list unsubscriptions from the victim list as a side effect of users reporting the spam, or where the attacker does POSTs directly to the mail sender's unsubscription server.

> The mail sender needs to provide the infrastructure to handle POST requests to the specified URI in the List-Unsubscribe header, and to handle the unsubscribe requests that its mail will provoke.

Re: CSRF protection without tokens or hidden form fields

#56

Post by flomo »

tptacek wrote: post #28
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"

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

Completely agree. But fyi there is a bunch of dev training stuff around this, implying like "don't do an owasp or you're in trouble".

Re: CSRF protection without tokens or hidden form fields

#57

Post by rfmoz »

Adding more security headers every year feels like strapping seatbelts onto a collapsing roller coaster. It would be better to stop this "sec headers stack" in favour of simpler, secure by default browser primitives with explicit opt-out. Getting an example from https://securityheaders.com the list nowadays is as follows:

- Strict-Transport-Security - Content-Security-Policy - X-Frame-Options - X-Content-Type-Options - Referrer-Policy - Permissions-Policy - Cross-Origin-Embedder-Policy - Cross-Origin-Opener-Policy - Cross-Origin-Resource-Policy

Re: CSRF protection without tokens or hidden form fields

#58

Post by t-writescode »

nchmy wrote: post #50
t-writescode wrote: post #16

Earlier quoted context omitted.

As I understand it, the moment you’re dealing with custom scripts, you’ve left the realm of a csrf attack. They’re dependent upon session tokens in cookies

Csrf is not dependent on js. It happens via normal links on external sites.

That's what I said, yes.

Re: CSRF protection without tokens or hidden form fields

#59

Post by thatwasunusual »

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.

>> FYI, HTTP headers are case insensitive

> Since when are they case sensitive?

[...]

Post reply on HN