[HN Gopher] Cross-Site Request Forgery
___________________________________________________________________
Cross-Site Request Forgery
Author : tatersolid
Score : 87 points
Date : 2025-08-13 17:31 UTC (5 hours ago)
(HTM) web link (words.filippo.io)
(TXT) w3m dump (words.filippo.io)
| nchmy wrote:
| i just discovered the Sec-Fetch stuff recently, due to Go 1.25's
| changelog. Very excited to start using it in some applications
| where tokens are currently used - what a hassle to deal with
| those.
| jerf wrote:
| Cookies have been truly horrible. I check in on them every
| couple of years, because I don't do a lot of front-end but when
| I do it's often security-sensitive, and every single time I
| check in on them there's some new entry in "SameSite;
| NoSeriouslySecureHarder;
| WhoopsTheLastStandardWasNotGoodEnough=BeActuallySecure;
| AwwShitDidWeGetItRightLastTime=false" parade of attributes you
| need to send to get actually secure cookies.
|
| No shade on the people implementing this stuff, I understand
| the backwards compatibility concerns, but I mean, keeping up
| with this stuff is harder than it should be. And thanks to
| backwards compatibility most of it still defaults open, though
| browsers have pecked at that as they can.
| pstuart wrote:
| Fortunately the stability and consistency of JS frameworks
| make light work of that pain!
| unethical_ban wrote:
| Your examples made me chuckle. I was thinking "God I hope
| frameworks deal with all this stuff".
| MajesticHobo2 wrote:
| Not sure I agree with this part:
|
| > Allow all GET, HEAD, or OPTIONS requests.
|
| > These are safe methods, and are assumed not to change state at
| various layers of the stack already.
|
| Plenty of apps violate this assumption and do allow GET requests
| to alter state.
| chrisfosterelli wrote:
| IMO apps that do this have a bug, and possibly a security one.
| This causes issues with prefetching, bot traffic, caching,
| CSRF, and just plain violates HTTP standards.
| pstuart wrote:
| Agreed. Those methods should be treated as idempotent.
| almog wrote:
| > Those methods should be treated as idempotent
|
| Idempotency still implies it can change state on the
| initial call, which to me feels wrong in the context of
| GET/HEAD/OPTIONS.
| Mavvie wrote:
| Indeed, the correct term here is nullipotent.
| simonw wrote:
| Those apps are beyond helping already. They need to fix
| theselves.
| nchmy wrote:
| The entire WordPress ecosystem says hello
| akersten wrote:
| I'm not really grokking the explanation in the article of why the
| SameSite cookie attribute doesn't fix CSRF. I thought that was
| the whole design intent of SameSite=Secure on an HTTPS cookie,
| was to fix CSRF. Can someone boil it down?
|
| The article seemingly says "these cookies won't be sent with an
| unsafe request. But that doesn't fix it!" And doesn't elaborate?
| MajesticHobo2 wrote:
| The problem boils down to the lack of equivalence between a
| site and an origin. The article explains how
| https://app.example.com and https://marketing.example.com may
| sit at very different trust levels, but are considered the same
| site by the browser. You don't want
| https://marketing.example.com to be able to make requests to
| https://app.example.com with your authentication cookies, but
| SameSite wouldn't prevent that.
| FiloSottile wrote:
| Same-Site cookies are, well, same-site. Not same-origin. This
| is already a deal-breaker for many deployments, because they
| don't trust blog.example.com and partner.example.com as much as
| admin.example.com (both in the strict sense of trust, and in
| the senso of not having XSS vulnerabilities the attacker can
| pivot off).
|
| Worse, by the original definition http://foo.example.com and
| https://admin.example.com are same-site, and unless the site
| uses HSTS with includeSubDomains, any network attacker controls
| the former. Chrome changed that with Schemeful Same-Site in
| 2020, but Firefox and Safari never deployed it.
| AgentME wrote:
| It's very nice to have an up-to-date writeup like this. I've
| gotten some odd looks for telling people that classic CSRF tokens
| are unnecessary work since the Origin header became widely
| supported, and I'm glad to have a page like this to refer people
| to.
| nchmy wrote:
| A few more links that I collected recently on the topic
|
| https://github.com/golang/go/issues/73626
|
| https://developer.mozilla.org/en-US/docs/Web/Security/Attack...
|
| https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
|
| https://web.dev/articles/fetch-metadata
|
| https://appliedgo.net/spotlight/csrf-dont-mess-with-my-site/
|
| And some older ones that focused on Origin header rather than
| sec-fetch-*
|
| https://www.sjoerdlangkemper.nl/2019/02/27/prevent-csrf-with...
|
| https://www.brandur.org/fragments/origin
|
| https://srungta.github.io/blog/start-right/ui-nonce
| fabian2k wrote:
| So am I understanding it right that you don't need any CSRF
| tokens anymore to fully protect against CSRF attacks?
|
| And if Go is implementing this specific protection, are other
| ecosystems doing this as well? My specific interest would be
| .NET/C#, but I am wondering in general how widespread this
| specific solution is at the moment.
___________________________________________________________________
(page generated 2025-08-13 23:00 UTC)