Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSRF protection without tokens or hidden form fields

blog.miguelgrinberg.com

Post reply on HN
Print view View original

101–110 of 116 posts

Re: CSRF protection without tokens or hidden form fields

#101

Post by hn_throwaway_99 »

alserio wrote: post #84
zenmac wrote: post #79

Earlier quoted context omitted.

Never needed the CSRF and assumed that cookies was always SameSite, but can see that it was introduced in 2016. Just had the sitename put into the value of the cookie since, and never really needed to think about that. Just feels like all these http specs are super duck tapped together. I guess that is only way to ensure mass adoption for new devs and now vibe coders.

I'm not sure I'm understanding your solution

Given what was written, I'm not quite sure the author does either.

Re: CSRF protection without tokens or hidden form fields

#102

Post by zenmac »

alserio wrote: post #84
zenmac wrote: post #79

Earlier quoted context omitted.

Never needed the CSRF and assumed that cookies was always SameSite, but can see that it was introduced in 2016. Just had the sitename put into the value of the cookie since, and never really needed to think about that. Just feels like all these http specs are super duck tapped together. I guess that is only way to ensure mass adoption for new devs and now vibe coders.

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.

Re: CSRF protection without tokens or hidden form fields

#103

Post by hn_throwaway_99 »

FiloSottile wrote: post #85
tmsbrg wrote: post #4

I'm surprised there's no mention of the SameSite cookie attribute, I'd consider that to be the modern CSRF protection and it's easy, just a cookie flag: https://scotthelme.co.uk/csrf-is-dead/ But I didn't know about the Sec-Fetch-Site header, good to know.

SameSite doesn’t protect against same-site cross-origin requests, so you are staking your app’s security on the security of the marketing blog.

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 all of your subdomains equally, which is rarely if ever the case.

I'm surprised browser vendors haven't thought of this. Like even SameSite: Strict will still send cookies when the request comes from a subdomain. Has there been any talk of adding something like a SameSite: SameOrigin or something like that? It seems weird to me that the Sec-Fetch-Site header has clear delineations between site and origin, but the SameSite header does not.

Re: CSRF protection without tokens or hidden form fields

#104

Post by scott_w »

tptacek wrote: post #99
scott_w wrote: post #96

Earlier quoted context omitted.

While you’re correct, corporate security teams demand suppliers “comply with OWASP,” despite this being a nonsensical statement to anyone who’d read the website. Unfortunately, the customer purchasing your product doesn’t know this and (naturally) trusts their own internal experts over you. Especially given all their other suppliers are more than happy to state they’re certified!

I'm, uh, pretty familiar with the routine. I stand by what I said: you do not need any particular CSRF defense in place; you need to not have CSRF vulnerabilities. There's no OWASP checkbox-alike that requires you to have CSRF tokens, and plenty of real line-of-business apps at gigantic companies don't.

To be fair, though, you’re a lot more knowledgeable and experienced than some security “experts” I’ve had to deal with ;-)

Re: CSRF protection without tokens or hidden form fields

#105

Post by FiloSottile »

hn_throwaway_99 wrote: post #103
FiloSottile wrote: post #85

Earlier quoted context omitted.

SameSite doesn’t protect against same-site cross-origin requests, so you are staking your app’s security on the security of the marketing blog.

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 prevention, it was privacy. CSRF is what Fetch metadata is for.

Re: CSRF protection without tokens or hidden form fields

#106

Post by jonway »

8n4vidtmkvmk wrote: post #30
owenthejumper wrote: post #2

Right now the problem is what the author already mentions - the use of Sec-Fetch-Site (FYI, HTTP headers are case insensitive :) - is considered defense in depth in OWASP right now, not a primary protection. Unfortunately OWASP rules the world. Not because it's the best way to protect your apps, but because the corporate overloads in infosec teams need to check the box with "Complies with OWASP Top 10"

Since when are they case sensitive? https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... says otherwise. It's possible for a server to treat them as case sensitive, but that seems like a bad idea.

My primitive instincts lead me to believe that sometimes they end up being Case-Sensitive and Sometimes NoT! (depending on implementation)

Re: CSRF protection without tokens or hidden form fields

#107

Post by rfmoz »

rfmoz wrote: post #82
thaumasiotes wrote: post #64

Earlier quoted context omitted.

Yeah, redoing the defaults would probably be good. On the other hand, I tried doing a Google search with javascript disabled today, and I learned that Google doesn't even allow this. (I also thought "maybe that's just something they try to pawn off on mobile browsers", but no, it's not allowed on desktop either.) So the state of things for "how should web browsers work?" seems to be getting worse, not better.

The reference of robots.txt offer a good way to define specific behavior for the whole domain, as example. Something like that for security could be enough for large amount of websites. Also, a new header like “sec-policy: foo-url” may be a clean way to move away that definitions from the app+web+proxy+cdn mesh to a fixed clear point.

I reply myself because I've found that idea already porposed:

"Origin policy was a proposal for a web platform mechanism that allows origins to set their origin-wide configuration in a central location, instead of using per-response HTTP headers." - https://github.com/WICG/origin-policy

But their status is "[On hold for now]" since, at least, three years ago.

Re: CSRF protection without tokens or hidden form fields

#108

Post by ImJamal »

varenc wrote: post #7
shermantanktop wrote: post #6

Am I missing something? The suggested protection helps with XSS flavors of CSRF but not crafted payloads that come from scripts which have freedom to fake all headers. At that point you also need an oauth/jwt type cookie passed over a private channel (TLS) to trust the input. Which is true for any sane web app, but still…

If an attacker has a user's private authentication token, usually stored in a __Host prefixed cookie, then it's game over anyway. CSRF is about protecting other sites forcing a user to make a request to a site they're authenticated to, when the malicious site doesn't actually have the cookie/token. CSRF is when you don't have the authentication token, but can force a user to make a request of your choosing that inclu…

How would you make SSO work without cross domain posts?

Re: CSRF protection without tokens or hidden form fields

#109

Post by ludwik »

zenmac wrote: post #79
hn_throwaway_99 wrote: post #43

Earlier quoted context omitted.

The only reason CSRF is even possible is because the browser sends (or, well, used to send) cookies for a particular request even if that request initiated from a different site. If the browser never did that (and most people would argue that's a design flaw from the get go) CSRF attacks wouldn't even be possible. The SameSite attribute makes it so that cookies will only be sent if the request that originated them is…

Never needed the CSRF and assumed that cookies was always SameSite, but can see that it was introduced in 2016. Just had the sitename put into the value of the cookie since, and never really needed to think about that. Just feels like all these http specs are super duck tapped together. I guess that is only way to ensure mass adoption for new devs and now vibe coders.

> Just had the sitename put into the value of the cookie since, and never really needed to think about that.

How would that help? This doesn't seem like a solution to the CSRF problem

Re: CSRF protection without tokens or hidden form fields

#110

Post by paulryanrogers »

eli wrote: post #49
paulryanrogers wrote: post #25

Earlier quoted context omitted.

Unsubscribe often need to be GET, or at least start as GET

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.
Post reply on HN