CSRF protection without tokens or hidden form fields • Hacker News Board

Re: CSRF protection without tokens or hidden form fields

#111

Post by hn_throwaway_99 » Fri, Dec 26, 2025, 12:06 AM UTC

zenmac wrote: post #102

alserio wrote: post #84

Earlier quoted context omitted.

I'm not sure I'm understanding your solution

If the domain name is in the cookie value then that can't be used when submit another request from another domain. Yes you can configure the dns to bypass that, but at that point it is also pointless for CSRF.

Not to be rude, but from your comments you don't appear to understand what the CSRF vulnerability actually is, nor how attackers make use of it.

Cookies can still only be sent to the site that originally wrote them, and they can only be read by the originating site, and this was always the case. The problem, though, is that a Bad Guy site could submit a form post to Vulnerable Site, and originally the browser would still send any cookies of Vulnerable Site with the request. Your comment about "if the domain name is in the cookie value" doesn't change this and the problem still exists. "Yes you can configure the dns to bypass that" also doesn't make any sense in this context. The issue is that if a user is logged into Vulnerable Site, and can be somehow convinced to visit Bad Guy site, then Bad Guy site can then take an action as the logged user of Vulnerable Site, without the user's consent.

Re: CSRF protection without tokens or hidden form fields

#112

Post by hn_throwaway_99 » Fri, Dec 26, 2025, 12:14 AM UTC

FiloSottile wrote: post #105

hn_throwaway_99 wrote: post #103

Earlier quoted context omitted.

Thanks very much for your comment. I posted elsewhere that I felt like SameSite: Lax should be considered a primary defense, not just "Defense in depth" as OWASP calls it, but your rationale makes sense to me, while OWASP's does not. That is, if you are using SameSite Lax and not performing state changes on GETs, there is no real attack vector, but like you say it means you need to be able to trust the security of al…

Browser vendors have absolutely thought about this, at length. The web platform is intricate, legacy, and critical. Websites by and large can’t and don’t break with browser updates, which makes all of these things like operating on the engine in flight. For example, click through some of the multiple iterations of the Schemeful Same Site proposal linked from my blog. Thing is, SameSite’s primary goal was not CSRF pre…

> Thing is, SameSite’s primary goal was not CSRF prevention, it was privacy.

That doesn't make any sense to me, can you explain? Cookies were only ever readable or writable by the site that created them, even before SameSite existed. Even with a CSRF vulnerability, the attacker could never read the response from the forged request. So it seems to me that SameSite fundamentally is more about preventing CSRF vulnerabilities - it actually doesn't do much (beyond that) in terms of privacy, unless I'm missing something.

Re: CSRF protection without tokens or hidden form fields

#113

Post by foobarkey » Fri, Dec 26, 2025, 3:51 AM UTC

I put the session cookie as http_only, same_site=strict and turned off csrf. Then pentesters came and quoted owasp in the report, while not being able to demonstrate an attack. Some drone added csrf back, everyone congratulated themselves in making things more secure :)

Re: CSRF protection without tokens or hidden form fields

#114

Post by deepsun » Fri, Dec 26, 2025, 3:58 AM UTC

> this would also reject HTTP clients that are not browsers

Why? I can send any headers from a client I make.

Re: CSRF protection without tokens or hidden form fields

#115

Post by eli » Sat, Dec 27, 2025, 12:55 AM UTC

paulryanrogers wrote: post #110

eli wrote: post #49

Earlier quoted context omitted.

list-unsubscribe header sends a POST. Probably makes more sense to just use a token from an email anyway.

I was thinking more about the unsubscribe footer links still very common in emails.

I don’t think CSRF has anything to do with those?

Re: CSRF protection without tokens or hidden form fields

#116

Post by paulryanrogers » Sat, Dec 27, 2025, 3:59 PM UTC

eli wrote: post #115

paulryanrogers wrote: post #110

Earlier quoted context omitted.

I was thinking more about the unsubscribe footer links still very common in emails.

I don’t think CSRF has anything to do with those?

The endpoints serving those links can't be protected as well. Unless they serve a form that posts, which may not be legal if it requires extra clicks