
Preventing CSRF with the same-site cookie attribute - hepha1979
http://www.sjoerdlangkemper.nl/2016/04/14/preventing-csrf-with-samesite-cookie-attribute/
======
madaxe_again
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
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
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
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)

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

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

~~~
edwinjm
Right. I said "nice addition".

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

~~~
voltagex_
Log a bug:
[https://bugs.php.net/search.php?search_for=setcookie&cmd=dis...](https://bugs.php.net/search.php?search_for=setcookie&cmd=display&status=Open&bug_type=All&project=All)

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

