HN Distilled

Essential insights from Hacker News discussions

Cross-Site Request Forgery

Original Article

Hacker News Discussion

Here's a summary of the themes discussed on Hacker News, with direct quotations from users:

The Complexity and Evolution of State-Changing GET Requests

A significant portion of the discussion revolves around the HTTP GET method and the assumption that it should be "safe" and not alter server-side state. Several users expressed concern that the article's premise, which allows GET, HEAD, and OPTIONS requests without specific restrictions, is problematic because many applications violate this principle.

  • "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."
    • MajesticHobo2: "Not sure I agree with this part: [...] Plenty of apps violate this assumption and do allow GET requests to alter state."
  • chrisfosterelli: "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: "Agreed. Those methods should be treated as idempotent."
  • almog: "Idempotency still implies it can change state on the initial call, which to me feels wrong in the context of GET/HEAD/OPTIONS."
  • Mavvie: "Indeed, the correct term here is nullipotent."
  • simonw: "Those apps are beyond helping already. They need to fix themselves."
  • The comment by "nchmy" citing "The entire WordPress ecosystem says hello" highlights a real-world example of this issue.

Challenges with Cookie Attributes and CSRF Protection

The conversation delves into the difficulties of managing cookie attributes, particularly SameSite, to prevent Cross-Site Request Forgery (CSRF). Users noted the evolving and often confusing nature of these attributes and their effectiveness.

  • jerf: "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."
  • akersten: "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?"
  • FiloSottile provided a detailed explanation regarding the "site" vs. "origin" distinction:
    • "For CSRF (and for SameSite), you are not looking at what cookies are sent to attacker.example.com, but what cookies are sent to target.example.com if a request is originated from attacker.example.com (or from attacker.com)."
    • "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."

The Promise of Fetch Metadata and Deprecation of CSRF Tokens

A key theme is the potential for newer security mechanisms, particularly Sec-Fetch headers, to replace traditional CSRF tokens. This is seen as a positive development that simplifies security management.

  • nchmy: "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."
  • AgentME: "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 also provided a list of helpful resources on the topic, indicating a community interest in these new approaches.
  • fabian2k: "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." This demonstrates a desire to understand the broader adoption of these modern security patterns.

Frameworks as a Solution to Security Complexity

The burden of managing complex security attributes and evolving standards is a point of frustration. Some users express hope that JavaScript frameworks can abstract away this complexity.

  • pstuart: "Fortunately the stability and consistency of JS frameworks make light work of that pain!"
  • unethical_ban: "Your examples made me chuckle. I was thinking 'God I hope frameworks deal with all this stuff'."

Specific Implementations and Cross-Ecosystem Adoption

The discussion touches upon specific implementations and queries about the adoption of these security features in different programming language ecosystems.

  • The mention of Go 1.25 by nchmy signals an interest in language-level support.
  • fabian2k's question about .NET/C# highlights the desire for cross-ecosystem understanding and adoption.
  • edoceo: "This doesn't match my experience. What am I doing different? Example I set SameSite=Strict on www.edoceo.com and then visiting app.edoceo.com the cookie is not there? They are different sites, different origins. And the cookie is set to the domain (ie: host, ie: www.edoceo.com)" This indicates hands-on experience and a need for clarification on how these rules are applied in practice, particularly concerning subdomains.