Same-site Cookies

https://tools.ietf.org/html/draft-west-first-party-cookies-07

by tosh • 10 years ago

121 33 10 years ago

tools.ietf.org

JetSpiegel• 10 years ago

Aren't all cookies same site already? You can just define a non wildcard domain.

jakub_g• 10 years ago

It is not about the domain scope of a cookie, but defining when should a cookie be attached to the outgoing http request.

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.

whatusername• 10 years ago

It would also limit protocols like SAML (HTTP-Post) but I guess that is to be expected from csrf measures.

mevile• 10 years ago

This is a welcomed change as it prevents unrelated sites from making XHRs to unrelated sites (already mitigated by browser restrictions with allow credentials and very loose Access-Control-Allow-Origin server headers) but I'd like to point out that if someone stole your cookies via a XSS request they could free themselves of browser restrictions by making requests by not using a browser.

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.

readams• 10 years ago

This is much more about CSRF than XSS.

elchief• 10 years ago

If you leave your windows open, your door lock isn't useful either.

tshadwell2• 10 years ago

The primary problem this hopes to solve is actually CSRF. Simply generating an HTML form for a website for any website and submitting it sends the cookies of the target website, regardless of where the form is based. XHR isn't so much of an issue as it has same origin policy restrictions.

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.

sintaxi• 10 years ago

Yep, CSRF is a completely opt-in problem to have. There is pretty much zero (valid) reasons to need Cookies anymore. Although I agree this spec is an improvement. Its main purpose should be to make legacy systems more secure. The best course of action would be to avoid cookies entirely.

andy_ppp2• 10 years ago

How does this work with something like Disqus/Facebook comments or other third party embedded plugins? Iframes only?

nostromo2• 10 years ago

It's an optional flag included in Set-Cookie, much like HttpOnly.

So, if you don't want to use it, you don't have to, and nothing will change.

andy_ppp2• 10 years ago

Cool, makes sense, thanks!

homakov2• 10 years ago

They should use localStorage

nostromo2• 10 years ago

I hope this is implemented by all browsers. It'll make CSRF prevention a whole lot easier.

However, I'm not sure I see any security improvements for applications that already prevent CSRF.

drdaeman• 10 years ago

It'll make CSRF prevention a whole lot easier.

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.

tetrep• 10 years ago

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.

moyok• 10 years ago

Looks like it has been implemented in only Chrome and Opera so far. No Microsoft Edge support, and Firefox support is under discussion. https://www.chromestatus.com/feature/4672634709082112

jrochkind1• 10 years ago

bout time.

jtchang• 10 years ago

I like the naming. Pretty clear that if you set the flag the cookies stay on the same site.

ComodoHacker• 10 years ago

Will this also help against tracking cookies?

gruez• 10 years ago

No, because it's on an opt in basis, controlled by the site.

mixedbit• 10 years ago

It seems that this can be used to easily disallow hotlinking of content. It should be enough for a content hosting site to set any cookie (doesn't need to be a secret cookie) with the Same-site parameter and drop all requests without the cookie.

stingraycharles• 10 years ago

Isn't that already possible without this ?

haikuginger• 10 years ago

Not really. Hotlink protections at present check the Referer header to see if the request was initiated by another site. Not only can this be bypassed on a browser level, HTML5 allows <a> tags to have the rel="noreferrer" attribute, which prevents the referrer from being set.

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.

hackuser• 10 years ago

For those interested in CSRF security in concept and in implementation, including cookie security, check out CsFire:

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.

driverdan• 10 years ago

Disable 3rd party cookies and everything will be treated as Same-site cookies. It's how browsers should be configured by default.

rshetty10• 10 years ago

Will this means we no longer need the CSRF token technique to protect against cross site requests ?

spookylukey• 10 years ago

The current spec has a serious flaw for CSRF prevention - it doesn't include the protocol in the definition of site, only the domain. This allows a MITM'd http page to CSRF a https site. This same flaw is in cookies themselves - a cookie set over https is used for http requests.

yclept• 10 years ago

I could be misunderstanding, but is that not what the secure cookie flag is for?

homakov2• 10 years ago

This is how cookies were supposed to work from very beginning. After two decades of vulnerable web apps finally fixes it with a flag, funny.

marco1• 10 years ago

I've added support for the 'SameSite' attribute in PHP here, in case anyone is interested: https://github.com/delight-im/PHP-Cookie

Same-site Cookies

Related Stories