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

41–50 of 104 posts

Re: A modern approach to preventing CSRF in Go

#41

Post by tankenmate »

nchmy wrote: post #37
tankenmate wrote: post #34

Earlier quoted context omitted.

indeed, you need some form of CSRF, but the Sec-Fetch-Site is primarily focused on keeping a browser secure, not the server. Having said that it's nice defence in depth for the server as well but not strictly required as far as the server is concerned.

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 more secure, but obviously requires more engineering (and comes with its own "usability" / "failure mode" trade offs).

Re: A modern approach to preventing CSRF in Go

#42

Post by nmadden »

nchmy wrote: post #27
nmadden wrote: post #9

Enforcing TLS 1.3 seems like a roundabout way to enforce this. Why not simply block requests that don’t have an Origin/Sec-Fetch-Site header?

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?

Re: A modern approach to preventing CSRF in Go

#43

Post by RagingCactus »

tankenmate wrote: post #33
hmry wrote: post #19

Earlier quoted context omitted.

CSRF is about preventing other websites from making requests to your page using the credentials (including cookies) stored in the browser. Cookies can't prevent CSRF, in fact they are the problem to be solved.

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 (such as bearer tokens in the authorization header) are not susceptible to CSRF, some are (such as cookies). The reason for that is just how they are implemented in browsers.

I don't mean to be rude, but I urge you to follow the recommendation of the other commenters and read up on what CSRF is and why it is not the same issue as authentication in general.

Clearly knowledgeable people not knowing about the intricacies of (web) security is actually an issue that comes up a lot in my pentesting when I try to explain issues to customers or their developers. While they often know a lot about programming or technology, they frequently don't know enough about (web) security to conceptualize the attack vector, even after we explain it. Web security is a little special because of lots of little details in browser behavior. You truly need to engage your suspension of disbelief sometimes and just accept how things are to navigate that space. And on top of that, things tend to change a lot over the years.

Re: A modern approach to preventing CSRF in Go

#44

Post by cryptonym »

anal_reactor wrote: post #30
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…

From business perspective it makes a lot of sense to just drop that bottom 5%. Actually, many businesses support Chrome only, they don't even support Firefox. Technological counterargument though is that you should allow people to tinker and do weird shit. Once upon a time tech wasn't about maximizing stock value, it was about getting Russian game crack to work, and making Lora's boobs bigger. Allowing weird shit is…

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

Re: A modern approach to preventing CSRF in Go

#45

Post by jeremyscanvic »

RagingCactus wrote: post #39
jeremyscanvic wrote: post #31

Earlier quoted context omitted.

Erratum: What I'm saying here only applies for cookies with the attribute SameSite=None so it's irrelevant here, see the comments below. (Former CTF hobbyist here) You might be mixing up XSS and CSRF protections. Cookie protections are useful against XSS vulnerabilities because they make it harder for attackers to get a hold on user sessions (often mediated through cookies). It doesn't really help against CSRF attack…

The SameSite cookie flag is effective against CSRF when you put it on your session cookie, it's one of its main use cases. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... for more information. SameSite=Lax (default for legacy sites in Chrome) will protect you against POST-based CSRF. SameSite=Strict will also protect against GET-based CSRF (which shouldn't really exist as GET is not a safe method…

Thanks for correcting me - I see my web sec knowledge is getting rusty!

Re: A modern approach to preventing CSRF in Go

#46

Post by kokada »

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?

If your case is just supporting browsers and not things like curl this seems fine. But when the headers are not set the CSRF protections are "disabled" exactly to support this case, that you may want to do this request using something like curl.

Re: A modern approach to preventing CSRF in Go

#47

Post by hmry »

RagingCactus wrote: post #39
jeremyscanvic wrote: post #31

Earlier quoted context omitted.

Erratum: What I'm saying here only applies for cookies with the attribute SameSite=None so it's irrelevant here, see the comments below. (Former CTF hobbyist here) You might be mixing up XSS and CSRF protections. Cookie protections are useful against XSS vulnerabilities because they make it harder for attackers to get a hold on user sessions (often mediated through cookies). It doesn't really help against CSRF attack…

The SameSite cookie flag is effective against CSRF when you put it on your session cookie, it's one of its main use cases. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... for more information. SameSite=Lax (default for legacy sites in Chrome) will protect you against POST-based CSRF. SameSite=Strict will also protect against GET-based CSRF (which shouldn't really exist as GET is not a safe method…

This page has some more information about the drawbacks/weaknesses of SameSite, worth a read: https://developer.mozilla.org/en-US/docs/Web/Security/Attack...

You usually need another method as well

Re: A modern approach to preventing CSRF in Go

#48

Post by kokada »

jebronie wrote: post #14
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…

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.

Re: A modern approach to preventing CSRF in Go

#49

Post by nchmy »

cryptonym wrote: post #44
anal_reactor wrote: post #30

Earlier quoted context omitted.

From business perspective it makes a lot of sense to just drop that bottom 5%. Actually, many businesses support Chrome only, they don't even support Firefox. Technological counterargument though is that you should allow people to tinker and do weird shit. Once upon a time tech wasn't about maximizing stock value, it was about getting Russian game crack to work, and making Lora's boobs bigger. Allowing weird shit is…

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"

Re: A modern approach to preventing CSRF in Go

#50

Post by RagingCactus »

hmry wrote: post #47
RagingCactus wrote: post #39

Earlier quoted context omitted.

The SameSite cookie flag is effective against CSRF when you put it on your session cookie, it's one of its main use cases. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... for more information. SameSite=Lax (default for legacy sites in Chrome) will protect you against POST-based CSRF. SameSite=Strict will also protect against GET-based CSRF (which shouldn't really exist as GET is not a safe method…

This page has some more information about the drawbacks/weaknesses of SameSite, worth a read: https://developer.mozilla.org/en-US/docs/Web/Security/Attack... You usually need another method as well

Yes, you're definitely right that there are edge cases and I was simplifying a bit. Notably, it's called SameSite, NOT SameOrigin. Depending on your application that might matter a lot.

In practice, SameSite=Lax is already very effective in preventing _most_ CSRF attacks. However, I 100% agree with you that adding a second defense mechanism (such as the Sec header, a custom "Protect-Me-From-Csrf: true" header, or if you have a really sensitive use case, cryptographically secure CSRF tokens) is a very good idea.

Post reply on HN