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

A modern approach to preventing CSRF in Go

alexedwards.net

Post reply on HN
Print view View original

71–80 of 104 posts

Re: A modern approach to preventing CSRF in Go

#71

Post by kijin »

nchmy wrote: post #70
kijin wrote: post #60

Earlier quoted context omitted.

If a browser is too old to send either the Sec-Fetch-Site header or the Origin header, it will probably ignore Referrer-Policy and always set the Referer header, which contains the origin. So I wonder why the author didn't consider falling back to the Referer header, instead of relying on an unrelated feature like TLS 1.3. Checking the referrer on dangerous (POST) requests was indeed considered one way to block CSRF…

Caniuse.com shows both origin and referer headers have 96.3% support, with Sec-Fetch-Site not far behind at 94.2. So it's probably a moot point. Ive read in various places though that referer has all sorts of issues, gotchas etc such that it isn't really a reliable way of doing this. https://security.stackexchange.com/questions/158045/is-check...

Caniuse.com looks wrong in this case. It marks old versions of Internet Explorer and Android browser as either unknown or not supporting Referer, when in fact they only lacked support for hiding the Referer in potentially insecure situations. That's the point I was trying to make above. Even old browsers send it, even when they shouldn't. This behavior is uncontrollable, even by potential attackers.

A missing Referer header probably doesn't mean much one way or another. But you can at least block requests with Referer pointing to URLs outside of your origin. This fallback would seem preferable to the fail-open policy described in the article (request always allowed if neither Sec-Fetch-Site nor Origin headers are present).

Re: A modern approach to preventing CSRF in Go

#72

Post by nchmy »

todotask2 wrote: post #67
cryptonym wrote: post #61

Earlier quoted context omitted.

Grandma or poor folk with their old device may not be "largely a choice"

It still depends on the target audience. Some websites or apps are single-page applications (SPAs), can older devices handle that? For example, my mum’s Android phone was too slow to even load a page. Secondly, users should upgrade their devices to stay safe online, since vulnerabile people are often scammed or tricked into downloading apps that contain malware. So we should not cater to outdated browsers when they c…

Yeah, I'm very amenable to this take. WordPress, for example, is infamous for having extreme backwards compatibility. But that often results in many sites being on ancient versions of php (and surely other tech as well). I'm of the opinion that they should all be running currently-supported versions of php and everything else. If you can't use my plugin because your server is shit, so be it.

Re: A modern approach to preventing CSRF in Go

#73

Post by nchmy »

littlestymaar wrote: post #69
nchmy wrote: post #65

Earlier quoted context omitted.

There's plenty of other chromium browsers - Vivaldi seems to do a good job in this regard. Also, Firefox exists, though they don't seem to care about privacy much anymore either. And, of course, safari, which is terrible in most regards

> There's plenty of other chromium browsers - Vivaldi seems to do a good job in this regard. Being chromium derivatives, they don't really have a say in what's included in “their” browser though. > Also, Firefox exists Well, you disregarded is as “arcane browser” right above.

In what way did I call Firefox arcane? Firefox generally has better support for web features than safari.

Re: A modern approach to preventing CSRF in Go

#74

Post by nchmy »

kokada wrote: post #48
jebronie wrote: post #14

Earlier quoted context omitted.

I don't understand why your post is flagged. You are 100% right. The point of CSRF protection is that -you can't trust the client-. This new header can just be set in curl, If I understand correctly. Unlimited form submissions here I come!

This is not what this is supposed to protect, and if you are using http.CrossOriginProtection you don't even need to add any header to the request: > If neither the Sec-Fetch-Site nor Origin headers are present, then it assumes the request is not coming from web browser and will always allow the request to proceed.

Wait, but if those headers are missing, then isn't there a vulnerability if someone is using an old browser and clicks on a malicious link? Do we need to also check user agent or something else?

Re: A modern approach to preventing CSRF in Go

#75

Post by littlestymaar »

nchmy wrote: post #73
littlestymaar wrote: post #69

Earlier quoted context omitted.

> There's plenty of other chromium browsers - Vivaldi seems to do a good job in this regard. Being chromium derivatives, they don't really have a say in what's included in “their” browser though. > Also, Firefox exists Well, you disregarded is as “arcane browser” right above.

In what way did I call Firefox arcane? Firefox generally has better support for web features than safari.

It has less than 5% market share left…

Re: A modern approach to preventing CSRF in Go

#76

Post by tankenmate »

nchmy wrote: post #51
tankenmate wrote: post #38

Earlier quoted context omitted.

There's server security and there's client security. From what I've seen in these comments people are focused on the client security and are either a) ignoring server security, or b) don't understand server security. But the server security is the primary security, because it's the one with the resources (in the money analogy it's the bank). So yes, we do want to secure the client, but if the attacker has enough cont…

Sorry, but you seem to be lost. I, the article and most comments here quite explicitly talked about server security via Auth and csrf protections. None of this has anything to do with browser security, such as stealing csrf tokens (which tend to be stored as hidden fields on elements in the html, not cookies). MOREOVER, Sec-Fetch-Site obviates the need for csrf tokens.

"MOREOVER, Sec-Fetch-Site obviates the need for csrf tokens.", you're just posting misinformation, you are flat out wrong.

"It is important to note that Fetch Metadata headers should be implemented as an additional layer defense in depth concept. This attribute should not replace a [sic] CSRF tokens (or equivalent framework protections)." -- OWASP; https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

Re: A modern approach to preventing CSRF in Go

#77

Post by tankenmate »

nchmy wrote: post #52
tankenmate wrote: post #41

Earlier quoted context omitted.

The Sec-Fetch-Site header can't be read / written by Javascipt (or WASM, etc), cookies (or some other tokens) on the other hand can be. In most circumstances allowing Javascript to access these tokens allows for "user friendly" interfaces where a user can log in using XMLHttpRequest / API rather than using a form on a page. OOB tokens one a one off auth basis or continuous (i.e. OAuth, TOTP with every request) are mo…

> The Sec-Fetch-Site header can't be read / written by Javascipt Perfect. It's not even meant or needed to be. The server uses it to validate the request came from the expected site. As i and others have said in various comments, you seem to be lost. Nothing you're saying has any relevance to the topic at hand. And, in fact, is largely wrong.

"Nothing you're saying has any relevance to the topic at hand. And, in fact, is largely wrong."; your confidence in your opinion doesn't make you right.

Prove it.

Re: A modern approach to preventing CSRF in Go

#78

Post by tankenmate »

FiloSottile wrote: post #20
tankenmate wrote: post #8

I would never rely on headers such as "Sec-Fetch-Site"; having security rely on client generated (correct) responses is just poor security modelling (don't trust the client). I'll stick to time bounded HMAC cookies, then you're not relying on client properly implementing any headers and it will work with any browser that supports cookies. And having TLS v1.3 should be a requirement; no HTTPS, no session, no auth, no…

No, in CSRF the browser is not the adversary, it is a confused deputy, and it’s perfectly reasonable to collaborate with it against the attacker (which is another site). You might want to read https://words.filippo.io/csrf .

You might want to read https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

Re: A modern approach to preventing CSRF in Go

#79

Post by tankenmate »

RagingCactus wrote: post #43
tankenmate wrote: post #33

Earlier quoted context omitted.

Somewhere auth needs to be done, somewhere, somehow, and some when. And this is done with cookies (be it CSRF, auth token, JWT, etc). There has to be some form of mechanism for a client to prove that a) it is the client it claims it is, and therefore b) it has the permission to request what it needs from the server. And, the server shouldn't trust the client "trust me bro" style. So, at the end of the day it doesn't…

I work as a pentester. CSRF is not a problem of the user proving their identity, but instead a problem of the browser as a confused deputy. CSRF makes it so the browser proves the identity of the user to the application server without the user's consent. You do need a rigid authentication and authorization scheme just as you described. However, this is completely orthogonal to CSRF issues. Some authentication schemes…

Of course CSRF is a form of authorisation; "should I trust this request? is the client authorised to make this request? i.e. can the client prove that it should be trusted for this request?", it may not be "logging in" in the classic sense of "this user needs to be logged into our user system before i'll accept a form submit request", but it is still a "can i trust this request in order to process it?" model. You can wrap it up in whatever names and/or mechanism you want, it's still a trust issue (web or not, form or not, cookie or not, hidden field or not, header or not).

Servers should not blindly trust clients (and that includes headers passed by a browser claiming they came from such and such a server / page / etc); clients must prove they are trustworthy. And if you're smart your system should be set up such that the costs to attack the system are more expensive than compliance.

And yes, I have worked both red team and blue team.

Re: A modern approach to preventing CSRF in Go

#80

Post by tankenmate »

nchmy wrote: post #35
tankenmate wrote: post #33

Earlier quoted context omitted.

Somewhere auth needs to be done, somewhere, somehow, and some when. And this is done with cookies (be it CSRF, auth token, JWT, etc). There has to be some form of mechanism for a client to prove that a) it is the client it claims it is, and therefore b) it has the permission to request what it needs from the server. And, the server shouldn't trust the client "trust me bro" style. So, at the end of the day it doesn't…

I don't think this is accurate. As your parent comment said, Csrf defenses (tokens, origin/Sec-Fetch-Site) serve a different purpose from Auth token/jwt. The latter says that your browser is logged in as a user. The former says "the request actually came from a genuine action on your page, rather than pwned.com disguising a link to site.com/delete-account. You're conflating the two types of Auth/Defense.

You're misunderstanding my point, the Sec-Fetch-Site is not a replacement for CSRF tokens (be they cookies (classic CSRF tokens, auth tokens, JWTs; all of these can be made to work for the client to prove to the server that they are allow to submit a form (and came from the "right" form), some obviously easier than others), a header (such as X-CSRF-Token - Ruby on Rails, Laravel, Django; X-XSRF-Token - AngularJS; CSRF-Token - Express.js (csurf middleware); X-CSRFToken - Django), a TOTP code, etc), but the Sec-Fetch-Site header is a defence in depth mechanism, not a replacement for CSRF (however that is achieved, classic cookie mechanism or other).
Post reply on HN