> Same site vs same site vs same origin
I'm lost here.
Cross-Site Request Forgery
31–38 of 38 posts
Re: Cross-Site Request Forgery
#32I'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 other replies answer this question, but it’s worth mentioning the public suffix list which contains a list of domain suffixes that have subdomains that are controlled by different people. E.g github.io, wordpress.com
Browser use this list to prevent cookie shared between sites using the suffixes on the list. E.g evil.github.io will not receive cookies from nice.github.io, or any other .github.io origin, regardless of the SameSite attribute
Re: Cross-Site Request Forgery
#33Not 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.
> Plenty of apps violate this assumption and do allow GET requests to alter state.
Yeah, that's not a justification. From a RESTful API design perspective, this just means plenty of apps are buggy/critical design problems. A bug in a random app does not mean HTTP verb lose their semantics.
Re: Cross-Site Request Forgery
#34So 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.
I don’t quite understand the part of the article that deems that you can skip all the checks under the assumption that this is an older browser, and that there is no CSRF vulnerability.
The algorithm seems sane for modern browsers. But you could probably find an outdated browser - older Android device WebView would be common -where the whole thing breaks down.
So I think tokens can be a thing of the past for modern browsers. I like the middleware, I hope it does show up in ASP.NET proper soon. My guess is they’ll keep tokens middleware around alongside it for some time once it does though, and the decision on which to use will come down to whether or not you want to make sure older browsers are secure.
Re: Cross-Site Request Forgery
#35Earlier quoted context omitted.
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
One click to perform an action and store data? Have you heard of HTML forms with method="post"?
Re: Cross-Site Request Forgery
#36Earlier quoted context omitted.
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
One click to perform an action and store data? Have you heard of HTML forms with method="post"?
[dead]
Re: Cross-Site Request Forgery
#37Not 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.
That's exactly why I don't agree that GETs should be broadly exempted from CSRF protections. I'm not talking about CORS at all.
Re: Cross-Site Request Forgery
#38[dead]