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

71–80 of 116 posts

Re: CSRF protection without tokens or hidden form fields

#71

Post by nchmy »

tptacek wrote: post #52
nchmy wrote: post #48

Earlier quoted context omitted.

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.

But that's not what owasp argues. Fetch Metadata is recommended as a primary, standalone defense against CSRF (you can be forgiven for not knowing this - I worked on getting the doc updated and it landed a couple weeks ago, then was reverted erroneously, and fixed yesterday)

Re: CSRF protection without tokens or hidden form fields

#72

Post by nchmy »

magmostafa wrote: post #67

This approach using Sec-Fetch-* headers is elegant, but it's worth noting the browser support considerations. According to caniuse, Sec-Fetch-Site has ~95% global coverage (missing Safari For production systems, a layered defense works best: use Sec-Fetch-Site as primary protection for modern browsers, with SameSite cookies as fallback, and traditional CSRF tokens for legacy clients. This way you get the UX benefits…

98% coverage if you exclude browsers that caniuse doesn't track (which is surely appropriate, since even things like checkbox elements have only 96% coverage if you include un tracked browsers).

And you can fall back to origin header, which has universal coverage. Then block anything else.

Also, owasp doesn't recommend it as defense in depth. It is a primary, standalone defense against CSRF.

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

Re: CSRF protection without tokens or hidden form fields

#73

Post by nchmy »

nchmy wrote: post #47
nhumrich wrote: post #23

Earlier quoted context omitted.

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.

Cs and cors have nothing to do with csrf... Though, yes, neither does same-site

I don't know why I said same-site cookies have nothing to do with csrf. They can be helpful as defense in depth, but not primary defense.

Re: CSRF protection without tokens or hidden form fields

#74

Post by nchmy »

NorwegianDude wrote: post #61

The simplest way to prevent CSRF is to use the Referer header, and that has been used since forever. If the header is missing, you no-op the post. Origin is similar, and can be used with referer as fallback, but it's not needed for most sites.

Fetch Metadata headers, as discussed in this post, are just as simple and much more effective. There's lots of issues with referer, and even some with origin.

Re: CSRF protection without tokens or hidden form fields

#75

Post by rocqua »

Macha wrote: post #12
rvnx wrote: post #8

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.

Note SameSite=Strict also counts against referrals too, which means your first request will appear unauthenticated. If this request just loads your SPA skeleton, that might be fine, but if you're doing SSR of any sort, that might not be what you want.

That's why someone suggested a non samesite cookie for reads and a samesite cookie for requests with side effects.

CSRF is mostly about causing side effects, not about access to information. And presumably just displaying your landing page should not have side effects, even when doing authenticated server side rendering. At least no side effects other than creating logs.

Re: CSRF protection without tokens or hidden form fields

#76

Post by nchmy »

vasco wrote: post #53

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

Sec fetch has 98% browser coverage now. You can fall back to origin, which has 100% coverage.

Non-browser clients can be either blocked or even just given a pass, since CSRF is about tricking someone into clicking a link that then sends their Auth cookie along with the request. Either the non-browser request includes a valid cookie in the request and is allowed to mutate state, or it doesn't and nothing happens as the request doesn't get authenticated.

Re: CSRF protection without tokens or hidden form fields

#77

Post by talkin »

NorwegianDude wrote: post #61

The simplest way to prevent CSRF is to use the Referer header, and that has been used since forever. If the header is missing, you no-op the post. Origin is similar, and can be used with referer as fallback, but it's not needed for most sites.

NO. Please don’t spread wrong solutions.

Your attempt has similarities to the idea behind Checking Sec-Fetch-Site. Implementing that header is the same amount of work. But this header is exactly meant for this purpose, and referer is haunted with problems.

So for officially intended protections, implementing this header and samesite cookies gets you a very long way without any complexity, assumptions, or tricks of old lore.

Re: CSRF protection without tokens or hidden form fields

#78

Post by _heimdall »

rfmoz wrote: post #57

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…

This is an extremely common approach across industries. Look into diesel engine emission control systems sometime if you aren't familiar. The last few decades has been bolting one new system on every dew years because the ones already added continue to cause unintended reliability problems.

Re: CSRF protection without tokens or hidden form fields

#79

Post by zenmac »

hn_throwaway_99 wrote: post #43
hatefulheart wrote: post #33

Earlier quoted context omitted.

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.

The only reason CSRF is even possible is because the browser sends (or, well, used to send) cookies for a particular request even if that request initiated from a different site. If the browser never did that (and most people would argue that's a design flaw from the get go) CSRF attacks wouldn't even be possible. The SameSite attribute makes it so that cookies will only be sent if the request that originated them is…

Never needed the CSRF and assumed that cookies was always SameSite, but can see that it was introduced in 2016. Just had the sitename put into the value of the cookie since, and never really needed to think about that.

Just feels like all these http specs are super duck tapped together. I guess that is only way to ensure mass adoption for new devs and now vibe coders.

Re: CSRF protection without tokens or hidden form fields

#80

Post by ozim »

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

If you look from perspective of vulnerability assessment, it kind of is.
Post reply on HN