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

Cross-Site Request Forgery

words.filippo.io

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Cross-Site Request Forgery

#21

Post by nchmy »

AgentME wrote: post #16

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.

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

Re: Cross-Site Request Forgery

#22

Post by [deleted] »

MajesticHobo2 wrote: post #6
akersten wrote: post #5

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?

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…

[deleted]

Re: Cross-Site Request Forgery

#23

Post by FiloSottile »

akersten wrote: post #5

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?

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.

Re: Cross-Site Request Forgery

#24

Post by edoceo »

MajesticHobo2 wrote: post #6
akersten wrote: post #5

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?

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…

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)

Re: Cross-Site Request Forgery

#25

Post by FiloSottile »

edoceo wrote: post #24
MajesticHobo2 wrote: post #6

Earlier quoted context omitted.

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…

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)

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).

Re: Cross-Site Request Forgery

#26

Post by pluto_modadic »

FiloSottile wrote: post #23
akersten wrote: post #5

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?

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-sit…

ah, that explains it.

Re: Cross-Site Request Forgery

#27

Post by cryptonector »

MajesticHobo2 wrote: post #4

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.

This is on the server side, on the app. If your supposedly-safe methods aren't safe, then CSRF may not be your biggest problem.

Re: Cross-Site Request Forgery

#29

Post by paulhodge »

MajesticHobo2 wrote: post #4

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.

That’s bad because visiting an evil site can easily trick your browser into performing one of those requests using your own credentials. CORS doesn’t stop the backend state effect from happening.

Re: Cross-Site Request Forgery

#30

Post by pinoy420 »

chrisfosterelli wrote: post #11
MajesticHobo2 wrote: post #4

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.

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.

Not really. If I have a service where I need one click to perform an action and store data. It has to be a GET. You can’t post from a url… purist dogma for the sake of purist dogma
Post reply on HN