Same-site Cookies
tools.ietf.org
tools.ietf.org
This is particularly a problem for sites that have XSS vulnerabilities and don't use the http only property for sensitive cookies and non-https sites on open wifi networks. Sites should use a combination of secure (cookies transmitted over https only) and http only (JS can't access the cookie) cookies and redirect all http traffic to https. Ad networks need to get better at helping sites monetize on https only traffic, it's a huge barrier for many sites making the switch and helping the internet finally relegating plain text http traffic to the history books.
This spec allows you to set cookies that turn this outdated and age-old security policy on its head, so instead of having to generate and validate cryptographically derived client-correlated tokens on every form (CSRF tokens), we can simply set this flag and refuse to send these cookies from any other site. This has long been known to be the right thing to do, which is why other new-age web policies like CORS refuse to send cookies completely by default.
The HttpOnly flag is meant to mitigate cookie theft risk via XSS. To my knowledge this particular innovation actually does nothing to that risk.
This proposal allows sites to set a cookie (essentially, an authorization token), that must be actively sent for data to be available, and which can only be sent when the site being browsed matches the domain on the cookie.
https://distrinet.cs.kuleuven.be/software/CsFire/
I've used it for many years. And in all that time I've only had to make a half-dozen rules (i.e., whitelist sites, though you can write the rule narrowly) to get specific sites working with it; otherwise it's invisible.
It's based on academic research; be sure to look around the site if you're interested.
However, I'm not sure I see any security improvements for applications that already prevent CSRF.
For a time being, it won't - unless you intend to only provide CSRF protection for the browsers that support this extension (and can server even detect whenever the UA is capable or not?). I think for at least a few years, Cookie+POST data is the only reliable option.
Not entirely. If you're willing to set headers you can do so as a trivial anti-CSRF measure. Just setting a header like "X-Totes-Not-CSRF" would suffice as CORS will prevent arbitrary sites from setting such a header. Its value does not matter.
Reference: https://docs.angularjs.org/api/ng/service/$http
This is an effective approach because unless an attacker has already compromised the relevant cookie, they will be unable to spoof the X-XSRF-TOKEN header in a cross-origin request. On the server-side, you just need to validate that (a) the X-XSRF-TOKEN header was sent and (b) it contains the expected value for each HTTP request received.
Right now when evil.com does XHR or form submission to google.com, browser attaches all google.com cookies automatically. The request happpens even though response can't be read back by evil.com. With SameSite attrib on all cookies, request to google.com from evil.com won't send any cookies. This will severely limit CSRF and other types of attacks.
In fact I'm surprised no one proposed this earlier. Hindsight bias of course.
So, if you don't want to use it, you don't have to, and nothing will change.