5 ms·

Preventing CSRF with the same-site cookie attribute

57 points by hepha1979 10y ago

madaxe_again 10y ago
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.
mixedbit 10y ago
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.
- bdupharm 10y ago
  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?
  - airza 10y ago
    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)
- deleted 10y ago
  [deleted]
- mrfusion 10y ago
  Gets are protected by the same origin policy, no?
  - mixedbit 10y ago
    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).
- homakov 10y ago
  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.
jwatte 10y ago
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)
- bdupharm 10y ago
  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.
  - edwinjm 10y ago
    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.
    - jwatte 10y ago
      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.
foota 10y ago
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)?
codedokode 10y ago
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.
- ec109685 10y ago
  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.
aruggirello 10y ago
Interestingly, it looks like there's no way to set the SameSite parameter in PHP setcookie(). Gotta reimplement it as header("Set-Cookie: ....")...
- voltagex_ 10y ago
  Log a bug: https://bugs.php.net/search.php?search_for=setcookie&cmd=display&status=Open&bug_type=All&project=All https://bugs.php.net/search.php?search_for=setcookie&cmd=dis...

57 points by hepha1979 10y ago

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.

mixedbit 10y ago

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.

bdupharm 10y ago
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?
- airza 10y ago
  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)
deleted 10y ago
[deleted]
mrfusion 10y ago
Gets are protected by the same origin policy, no?
- mixedbit 10y ago
  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).
homakov 10y ago
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.

jwatte 10y ago

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)

bdupharm 10y ago
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.
- edwinjm 10y ago
  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.
  - jwatte 10y ago
    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.

foota 10y ago

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

codedokode 10y ago

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.

ec109685 10y ago
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.

aruggirello 10y ago

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

voltagex_ 10y ago
Log a bug: https://bugs.php.net/search.php?search_for=setcookie&cmd=display&status=Open&bug_type=All&project=All https://bugs.php.net/search.php?search_for=setcookie&cmd=dis...