Skip to content
Naked Security Naked Security

Chrome browser pushes SameSite cookie security overhaul

Slowly but steadily, developers are being given the tools with which to tame the promiscuous and often insecure world of the browser cookie.

Slowly but steadily, web developers are being given the tools with which to tame the promiscuous and often insecure world of the browser cookie.

The latest big idea is an IETF standard called SameSite (aka RFC6265bis), which Google and Mozilla have promoted since 2016 and the former announced this week it will start pushing more aggressively in Chrome from version 76 this July.

Cookies look simple on the surface – they’re a little chunk of text data that a website can ask your browser to remember, and that your browser will return to that website whenever the browser fetches a page, image or anything else from it. As a security measure, cookies can only be handed over to the domain that set them.

The most common use for cookies is user identification – a site stores an ID in a cookie and the browser returns that ID with each request, so that the site knows who it’s talking to. It’s this simple technique that allows sites to provide authentication and personalisation.

What gives cookies a bad name are third-party cookies, usually put there by advertisers or social media giants as a way of tracking users across sites.

For example, if a user visits a page on example.org with a Facebook button on it, their browser fetches that button from facebook.com as the page is loaded. As with any HTTP interaction, the browser will include any facebook.com cookies in the request to Facebook, along with a referrer header saying what page on example.org the request is coming from.

If you happen to be logged into Facebook (and even sometimes if they aren’t), that request for a button reveals to Facebook who you are, which page you visited and when.

If a social media or advertising company can persuade enough sites to include code hosted on a domain they own, they can turn these cookies into cross-site trackers that build up a map of each user’s behaviour and interests as they browse the web.

And that’s why some users regularly clear them from browser caches or resort to ad blocking or privacy plugins – clunky but effective solutions that can stop sites working correctly.

The consequences of this behaviour aren’t limited to tracking, it can also lead to major security hazards such as Cross-Site Request Forgery (CSRF) attacks.

To simplify, if a user leaves a site (a bank, say) without logging out, in theory it’s possible for a second, malicious, site to fool that user into making unseen requests to the bank that exploit the fact that the user is still logged in.

Perhaps the biggest flaw in this architecture then, is the assumption that just because a browser can hand over a cookie, it should.

How will SameSite help?

Adding SameSite support to Chrome (Firefox, Safari and Edge added experimental support last year) will require web developers to control cookies using the SameSite attribute of the Set-Cookie header, which can be Strict, Lax, or None.

In effect, these are a way of controlling which cookies can be sent by the browser and under what circumstances, doing away with the notion that a browser should send a site a cookie just because it can.

A cookie set to Strict will only be accessible when you’re visiting the domain that set it. If you visit a different site where content from that domain is included, the cookies will not be sent home.

The Strict setting is also a long-overdue way to counter the risk of CSRF attacks.

Alternatively, setting Lax will allow cookies to be made available to third parties via HTTP GET requests, but not by other methods such as POST. This won’t be enough to block a lot of tracking but it will blunt CSRF attacks.

Finally, there’s None, which simply allows a cookie to be accessed in the same way it is today.

Good news for security and, with fewer cookies flying around, privacy too. Cookies will be either same-site and restricted or one of two states of cross-site.

Commented Google’s director of Chrome product management, Ben Galbraith:

It will also enable browsers to provide clear information about which sites are setting these cookies, so users can make informed choices about how their data is used.

Google would also look to limit cross-site cookies where SameSite=None to HTTPS connections as a way of further boosting the privacy effect, he added.

Because Google, unlike many advertising rivals, has little to lose from SameSite (i.e. the popularity of Chrome and Google’s ubiquitous services, including DoubleClick ads), there’s controversy about its intentions.

It’s another example of the internet’s privacy paradox – big tech companies seem happy to promote privacy so long as it doesn’t stop them peeking behind the curtain.

Reforming cookies will also take more than inventing new cookie attributes. Today, most sites set cookies without a SameSite attribute and it will take some time for them to support the new format.

Chrome 76 offers a hint of how Google might hurry that process along. It introduces a cookies-without-same-site-must-be-secure flag that users can set so that Chrome assumes all cookies without a SameSite value are set to SameSite=Lax.

If Google applies the approach it took to HTTPS adoption to cookies, we can expect to see that flag being set by default, and the value ramped up, in later versions.

4 Comments

I like the idea, but I would prefer a default of `same-site=strict` instead of lax. And maybe a way to force some domains to be treated as strict as well, since the cookie setter is the one in control of strict and lax, so they could probably still engage in cross site tracking.

Reply

I hope we’ll also be given a new delete cookies option, in our browsers: delete all non-Strict. That should enable us to stop (to the extent it’s possible to stop) the tracking, without losing our logged-in sessions, etc. As a bonus, it would also encourage the web authors to update their sites to set Strict on all the cookies that really do improve the user experience.

Let’s hope this all takes off just before legislators or competition authorities force Google and Microsoft to shift their advertising operations into separate business units using distinct domain names.

Reply

The example of Facebook button on a web site just goes to show we have more then just a Cookie issue, we have companies like Facebook who don’t care about privacy in the least and they have proved this many times over. Pretty sure Google won’t shoot itself in the foot either as they still make most of their revenue from ads. Honestly I would believe a Microsoft or Mozilla before I would believe a Google or Facebook that they are truly concerned for my privacy.

Reply

Browser addon to change all cookies to SameSite=Strict on creation and during every edit, anyone?

Still not going to achieve much other than give Goggle marks with the public and legislators who don’t understand how it all works, but ho hum, steps in the right direction are still steps in the right direction.

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!