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

1–10 of 38 posts

Re: Cross-Site Request Forgery

#2

Post by 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.

Re: Cross-Site Request Forgery

#3

Post by jerf »

nchmy wrote: post #2

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.

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.

Re: Cross-Site Request Forgery

#4

Post by MajesticHobo2 »

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.

Re: Cross-Site Request Forgery

#5

Post by 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?

Re: Cross-Site Request Forgery

#6

Post by MajesticHobo2 »

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.

Re: Cross-Site Request Forgery

#7

Post by [deleted] »

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?

[deleted]
Post reply on HN