Live data from Hacker News

A modern approach to preventing CSRF in Go

alexedwards.net

1–10 of 104 posts

Re: A modern approach to preventing CSRF in Go

#4
CSRF: Cross-Site Request Forgery

From https://developer.mozilla.org/en-US/docs/Web/Security/Attack...

In a cross-site request forgery (CSRF) attack, an attacker tricks the user or the browser into making an HTTP request to the target site from a malicious site. The request includes the user's credentials and causes the server to carry out some harmful action, thinking that the user intended it.

Re: A modern approach to preventing CSRF in Go

#6
Are CSRF attacks that common nowadays though? Even if your app is used by the 5% of browsers that don’t set the Origin header the chances of that being exploited are even more miniscule. Besides, most webdevs reach for token-based auth libraries before even knowing how to set a cookie header.

Re: A modern approach to preventing CSRF in Go

#7
post #6

Are CSRF attacks that common nowadays though? Even if your app is used by the 5% of browsers that don’t set the Origin header the chances of that being exploited are even more miniscule. Besides, most webdevs reach for token-based auth libraries before even knowing how to set a cookie header.

Yes

Re: A modern approach to preventing CSRF in Go

#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 form (or API), no cookie. And having HSTS again should be default but with encrypted connections and time bounded CSRF cookies the threat window is very small.

Post reply on HN