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

81–90 of 104 posts

Re: A modern approach to preventing CSRF in Go

#81

Post by [deleted] »

tankenmate wrote: post #80
nchmy wrote: post #35

Earlier quoted context omitted.

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; CSR…

[deleted]

Re: A modern approach to preventing CSRF in Go

#82

Post by [deleted] »

tankenmate wrote: post #77
nchmy wrote: post #52

Earlier quoted context omitted.

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

[deleted]

Re: A modern approach to preventing CSRF in Go

#83

Post by dagss »

tankenmate wrote: post #79
RagingCactus wrote: post #43

Earlier quoted context omitted.

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…

You say you should "never trust the client". Well trust has to be established somehow right, otherwise you simply cannot allow any actions at all (airgap).

Then, CSRF is preventing a class of attacks directed against a client you actually have decided to trust, in order to fool the client to do bad stuff.

All the things you say about auth: Already done, already checked. CSRF is the next step, protecting against clients you have decided to trust.

You could say that someone makes a CSRF attack that manages to change these headers of an unwitting client, but at that point absolutely all bets are off you can invent hypothetical attacks to all current CSRF protection mechanisms too. Which are all based on data the client sends.

(If HN comments cannot convince you why you are wrong I encourage you to take the thread to ChatGPT or similar as a neutral judge of sorts and ask it why you may be wrong here.)

Re: A modern approach to preventing CSRF in Go

#84

Post by kokada »

nchmy wrote: post #74
kokada wrote: post #48

Earlier quoted context omitted.

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?

Exactly, the post talks about this too: older browsers will be vulnerable, this probably affects only a small amount of the population and it is even lower if you limit service to accept TLSv1.3 (for this to be useful you of course need to enable HTTPS otherwise the attacker can just strip the headers from your request).

If you can't afford to do this you still need to use CSRF tokens.

Re: A modern approach to preventing CSRF in Go

#85

Post by tankenmate »

dagss wrote: post #83
tankenmate wrote: post #79

Earlier quoted context omitted.

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…

You say you should "never trust the client". Well trust has to be established somehow right, otherwise you simply cannot allow any actions at all (airgap). Then, CSRF is preventing a class of attacks directed against a client you actually have decided to trust, in order to fool the client to do bad stuff. All the things you say about auth: Already done, already checked. CSRF is the next step, protecting against clien…

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

Re: A modern approach to preventing CSRF in Go

#86

Post by dagss »

tankenmate wrote: post #85
dagss wrote: post #83

Earlier quoted context omitted.

You say you should "never trust the client". Well trust has to be established somehow right, otherwise you simply cannot allow any actions at all (airgap). Then, CSRF is preventing a class of attacks directed against a client you actually have decided to trust, in order to fool the client to do bad stuff. All the things you say about auth: Already done, already checked. CSRF is the next step, protecting against clien…

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

Yes, this is documenting one particular way of doing CSRF. A specific implementation.

The OP is documenting another implementation to protect against CSRF, which is unsuitable for many since it fails to protect 5% of browsers, but still an interesting look at the road ahead for CSRF and in some years perhaps everyone will change how this is done.

And you say isn't OK, but have not in my opinion properly argued for why not.

Re: A modern approach to preventing CSRF in Go

#87

Post by nchmy »

kokada wrote: post #84
nchmy wrote: post #74

Earlier quoted context omitted.

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?

Exactly, the post talks about this too: older browsers will be vulnerable, this probably affects only a small amount of the population and it is even lower if you limit service to accept TLSv1.3 (for this to be useful you of course need to enable HTTPS otherwise the attacker can just strip the headers from your request). If you can't afford to do this you still need to use CSRF tokens.

I suppose that we could just reject anything that doesnt have these tokens, depending on whether you want to allow curl etc... I might just do that, in fact.

Re: A modern approach to preventing CSRF in Go

#88

Post by alex_edwards »

makkes wrote: post #18

The code he provides doesn't compile and needs to be changed like so: --- main_before.go 2025-10-15 09:56:16.467115934 +0200 +++ main.go 2025-10-15 09:52:14.798134654 +0200 @@ -13,8 +13,10 @@ slog.Info("starting server on :4000") + csrfProt := http.NewCrossOriginProtection() + // Wrap the mux with the http.NewCrossOriginProtection middleware. - err := http.ListenAndServe(":4000", http.NewCrossOriginProtection(mux)) +…

Thanks for pointing this out, what a facepalm. I've fixed it in the post.

Re: A modern approach to preventing CSRF in Go

#89

Post by nmadden »

kokada wrote: post #46
nmadden wrote: post #42

Earlier quoted context omitted.

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.

I guess. But it would only impact you if you’re using cookies with curl (I assume the middleware is only applied to requests with cookies?) — and it seems pretty easy to add a -H ‘sec-fetch-site: none’ in that case.
Post reply on HN