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

51–60 of 104 posts

Re: A modern approach to preventing CSRF in Go

#51

Post by nchmy »

tankenmate wrote: post #38
nchmy wrote: post #28

Earlier quoted context omitted.

I must be missing something. What does JavaScript have to do with this? My understanding is that csrf is about people getting tricked into clicking a link that makes, for example, a post request to another site/origin that makes an undesired mutation to their account. If the site/origin has some sort of Auth (eg session cookie), it'll get sent along with the request. If the Auth cookie doesn't exist (user isn't logge…

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.

Re: A modern approach to preventing CSRF in Go

#52

Post by nchmy »

tankenmate wrote: post #41
nchmy wrote: post #37

Earlier quoted context omitted.

I'm confused. In my mind, you only really need to keep the server secure, as that's where the data is. Auth cookies and csrf protections (eg Sec-Fetch-Site) are both used towards protecting the server from invalid requests (not logged in, or not coming from your actual site). What are you referring to when you talk about keeping the browser secure?

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.

Re: A modern approach to preventing CSRF in Go

#53

Post by johannes1234321 »

nchmy wrote: post #25

I deeply appreciate this thorough review of CSRF protection via headers. I've been looking into the topic to see if I can get rid of csrf tokens, and it seems like I can now - if I ignore/don't care about the 5% of browsers that don't support the required headers. It makes me wonder though - most browser APIs top out around 95% coverage on caniuse.com. What are these browsers/who are these people...? The modern web i…

Those 5% are probably a wild collection of devices. TVs with embedded Browsers, old phones and other computers elsewhere.

As example: my late grandfather of 100 years took records of his stamp collection in Excel. He used the computer for Wikipedia as well, but we didn't upgrade ist as he was comfortable, but upgrading to later Windows to ruin newer browser would have been too much of a change and rather made him stop doing what brought him fun. The router etc blocked worst places frequent backups allowed restore, thus actual risk low.

Anecdote aside: there are tons of those machines all over.

And then another big one: bots claiming to be something which they aren't.

Re: A modern approach to preventing CSRF in Go

#54

Post by brokegrammer »

nchmy wrote: post #26
dorianmariecom wrote: post #24

rails solved this a while ago ;)

I don't use rails. How did they solve it?

>Have we finally reached the point where CSRF attacks can be prevented without relying on a token-based check (like double-submit cookies)?

Rails uses a token-based check, and this article demonstrates token-less approach.

Rails didn't solve CSRF btw, the technique was invented long before Rails came to life.

Re: A modern approach to preventing CSRF in Go

#55

Post by nchmy »

nmadden wrote: post #42
nchmy wrote: post #27

Earlier quoted context omitted.

I don't understand - the article is literally about origin/Sec-Fetch-Site

The article has a whole section about requiring those headers by forcing the use of TLS 1.3 — the theory being that browsers modern enough to support 1.3 are also modern enough to support the headers. But why not just enforce the headers?

I see what you mean. You were saying why tls in addition to Sec-Fetch-Site. The sibling comment seems to have addressed it

Re: A modern approach to preventing CSRF in Go

#56

Post by nchmy »

brokegrammer wrote: post #54
nchmy wrote: post #26

Earlier quoted context omitted.

I don't use rails. How did they solve it?

>Have we finally reached the point where CSRF attacks can be prevented without relying on a token-based check (like double-submit cookies)? Rails uses a token-based check, and this article demonstrates token-less approach. Rails didn't solve CSRF btw, the technique was invented long before Rails came to life.

Yes, I assumed this is what they were ignorantly pointing towards.

Indeed, Csrf tokens are an ancient concept. WordPress, for example, introduced nonces a couple years before rails. Though, it does appear that rails might have been thr first to introduce csrf protection in a seemingly automated way.

Re: A modern approach to preventing CSRF in Go

#57

Post by littlestymaar »

nchmy wrote: post #49
cryptonym wrote: post #44

Earlier quoted context omitted.

Empathy and accessibility. Does it make sense to have a ramp in front of your shop for < 5% customers?

My question, though, is who are the 5% of users in this case who are using some arcane browsers? Surely that's largely a choice, physical disabilities are not. It doesn't seem unreasonable to say to those folks "were evidently not using the same web"

It's not comparable to a physical disability byt gatekeeping the people who just don't want to be tracked all day by Google doesn't sounds right to me though.

Re: A modern approach to preventing CSRF in Go

#58

Post by seethishat »

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…

It's very complicated and ever evolving. It takes dedicated web app pentesters like you to keep up with it... back in the day, we were all 'generalists'... we knew a little bit about everything, but those days are gone. It's too much and too complicated now to do that.

Re: A modern approach to preventing CSRF in Go

#59

Post by veeti »

johannes1234321 wrote: post #53
nchmy wrote: post #25

I deeply appreciate this thorough review of CSRF protection via headers. I've been looking into the topic to see if I can get rid of csrf tokens, and it seems like I can now - if I ignore/don't care about the 5% of browsers that don't support the required headers. It makes me wonder though - most browser APIs top out around 95% coverage on caniuse.com. What are these browsers/who are these people...? The modern web i…

Those 5% are probably a wild collection of devices. TVs with embedded Browsers, old phones and other computers elsewhere. As example: my late grandfather of 100 years took records of his stamp collection in Excel. He used the computer for Wikipedia as well, but we didn't upgrade ist as he was comfortable, but upgrading to later Windows to ruin newer browser would have been too much of a change and rather made him sto…

There are a lot of people happily browsing away on unsupported Apple devices that don't get any more Safari updates. Lot of strange webkit edge cases to be found that don't exist in any other browser.

Re: A modern approach to preventing CSRF in Go

#60

Post by kijin »

nchmy wrote: post #25

I deeply appreciate this thorough review of CSRF protection via headers. I've been looking into the topic to see if I can get rid of csrf tokens, and it seems like I can now - if I ignore/don't care about the 5% of browsers that don't support the required headers. It makes me wonder though - most browser APIs top out around 95% coverage on caniuse.com. What are these browsers/who are these people...? The modern web i…

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 back in the day. Assuming all your pages are on the same https origin, is there an edge case that affects Referer but not the Origin header?

Post reply on HN