Preventing CSRF with the same-site cookie attribute | Hacker News Reader

Preventing CSRF with the same-site cookie attribute

sjoerdlangkemper.nl

57 pointshepha197919 comments

Nice and easier than nonce tokens, particularly when you're partial view caching etc. - but until all current and old browsers that don't support the new attribute die out it's going to be necessary to continue doing things the old (current) way - users using older browsers are more likely to be hit by CSRF and other attacks as they tend to be more technically naive and actually click phishing emails/popups etc.

One nice thing about this approach is that it also protects GET requests, which in many cases are impossible to protect with CSRF tokens. CSRF protection for GET requests is considered less crucial, because correctly designed GETs can not change state of resources, so can not perform any sensitive action. But GETs can leak sensitive information, like for example the fact that the user is logged into certain services. With same-site attribute this problem should be solved.

I thought that an attacker's JS code can't read the response from a GET request in a CSRF attack. Or are you saying it's possible for the attacker to read the HTTP status code of the response?

I think you're correct here. Also, like POST-based CSRF, get-based CSRF is also a solved problem (issue a param in the URL)

Gets are protected by the same origin policy, no?

Get content is protected, but error status is not. For example a site can check if an image that is shown only to logged users of some other site loads successfully (this leaks if a user is logged).

Yes, in rare cases other windows leak status codes e.g. timing attack on location.history.

Other than this, this feature is a bad idea and shouldn't be implemented. Neither fixes any unsolved problem, nor does it gracefully.

Is there a reason they can't implement a whitelist option for this? Something like a list of domain patterns for which lax mode is enabled (and possibly a superlax mode that would allow CSRF like behavior in some cases)?

Unfortunately, most of these web security standards don't work for real sites. When my app server serves a page that uses services from another subdomain, this breaks. When I use a CDN to cache contents, this breaks. When I terminate HTTPS and web auth at a reverse proxy and forward the request to a HTTP server, the proxy needs to know about all decisions the app server would make about origins. (The exact reasons get complex, but most of these origin policies are /not/ friendly to non-trivial site deployments)

I definitely have to agree with this. It has lead to "it works in my sandbox" but breaks in our staging enviromemnt issues at work since everything in staging goes through a proxy.

Well, I don't agree. It is certainly a nice addition to make the web more secure. I hope my bank (and every other significant website) won't toss my auth tokens to different domains. And about reverse proxies: it's a browser feature, so how can reverse proxies be a problem? The browser doesn't care what's happening behind a reverse proxy.

Yes, let's make the web more secure!

This doesn't do that.

Instead, let's solve zero day advertising payloads.

Let's fund a cure for email spam and phishing.

Let's find a cure for site spoofing.

Let's find a cure for "this dialog means I have to click OK to get on with things."

Regarding "domains are controlled," that doesn't matter. If I want to serve pages from www.mydomain and static/CDN content from static.mydomain and services from api.mydomain, those are different domains.

The main solution for a big site is to build all the credential and security logic into the load balancer/HTTPS terminator, which is an almost-guarantee to get version skew and security holes.

All this "secure web" intention only works for small monolithic sites, and don't even solve the real security problems on the web.

Right. I said "nice addition".

I think a great deal of the problem is more that the new security standards don't work for any existing sites (to speak of). Retrofitting these things on to existing sites is more work than most people are willing to take on. (I am aware of some exceptions, but many of those exceptions got there only via paying out on quite a few bug bounties first.) They're really only useful for new sites. Some of them are only useful for new sites that are security-conscious, too... my bank's web access portal touches only three domains, all owned by the bank. (Although I'm suspicious about the check-ordering component, which I didn't count in that 3.) They going to have an easier time implementing this sort of feature than someone trying to bring in twelve different advertisers and trackers and dicking around with iframes and whoknowswhat.

But if you never put them in the browsers because "nobody" can use them, it is a certainty that nobody ever will.

Personally, I can't say as I mind some security features that will discourage splaying web sites across dozens of unrelated domains....

Isnt the whole purpose of a CDN to be stateless and only serve all the heavy static assets? It shouldnt require any cookies.

Interestingly, it looks like there's no way to set the SameSite parameter in PHP setcookie(). Gotta reimplement it as header("Set-Cookie: ....")...

Log a bug: https://bugs.php.net/search.php?search_for=setcookie&cmd=dis...

I don't think it will help. Sites that care about CSRF are already implementing protection (via CSRF tokens) and those who don't care won't use this feature.

The main problem is that browsers allow POSTing data cross-site by default instead of blocking such requests unless it is allowed explicitly.

This proposal will protect you from a bug where csrf isn't properly protected. If you know that there aren't any cases where cross site POSTing is allowed, you can block them with this proposal.

Reply on news.ycombinator.com