Improving privacy and security on the web

https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html

by migueldemoura • 7 years ago

121 60 7 years ago

blog.chromium.org

Ajedi322• 7 years ago

Interesting. So apparently Chrome is going to stop sending cookies in cross-site requests unless they're created with `CrossOrigin=None` and the page is loaded over HTTPS?

mikewest3• 7 years ago

We're proposing treating cookies as `SameSite=Lax` by default (https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03...). Developers would be able to opt-into the status quo by explicitly asserting `SameSite=None`, but to do so, they'll also need to ensure that their cookies won't be delivered over non-secure transport by asserting the `Secure` attribute as well.

https://tools.ietf.org/html/draft-west-cookie-incrementalism spells out the proposal in a bit more detail.

Boulth• 7 years ago

This is exactly the information I was looking for when I opened chromium blog post. Technical and to the point. Is there a reason why this couldn't be appended to the blog post?

est31• 7 years ago

Have you done some crawling or other means of checking as to how many web pages with a login your change would break?

raxxorrax• 7 years ago

I think this is a well thought out proposal. Thank you for going in that direction. Privacy and security should come first.

I would even go so far to substitute "should" with "must". But it is a first step.

34r45sdg• 7 years ago

Is this another way for Google to prevent you from clearing their cookies via the 'Clear Cookies' option?

Its a step in the right direction with enforcing SameSite cookie scoping, but we must be cautious that Google doesn't use this to force you to always be logged in. Google has a long way to go to rebuild trust after that last browser login debacle. I don't trust em.

wheelerwj• 7 years ago

google will absolutely not do anything in the name of trust and privacy as we define them because their business model is 100% about selling ads to more people.

jakub_g• 7 years ago

It's a way to fix one of the biggest security mistakes of the web (being able to send an _authenticated_ request - i.e. with cookies - to any domain from any other domain, for example from evil.com to youremailprovider.com with the payload "delete all emails"), that was kept on by default for two decades due to backward compatibility.

For a long time it required annoying workarounds (CSRF tokens) to have this security hole mitigated, then just an opt-in flag on the cookies, but as usual, most companies don't know/care about it, so having protection by default is the natural solution (although it _will_ probably break quite a few legacy websites, but for a greater good).

incompatible2• 7 years ago

Does Chrome support automatically clearing cookies at shutdown yet? I seem to remember it didn't but I haven't used it recently.

Edit: I searched for it, and it seems they have added the feature, but maybe not the related feature of clearing browsing history at shutdown.

jedimastert• 7 years ago

Isn't that exactly what Incognito mode does?

techntoke3• 7 years ago

Really disappointed in you Google for not addressing fingerprinting much sooner.

tptacek8• 7 years ago

Be disappointed all you want, but they're not really "addressing" fingerprinting. It is exceptionally difficult --- computer-science Hard difficult --- to prevent fingerprinting; all you can really do is break popular libraries people use today. It's an arms race, and a much harder arms race than exploit-hardened runtimes are.

techntoke3• 7 years ago

It's actually pretty easy overall... just don't use JavaScript and don't send user-agent string that shows browser/OS information.

tomjen32• 7 years ago

Is it? As I understand it, fingerprinting relies on properties and headers, both of which could be altered (eg adding headers for software that doesn't exist, and only sometimes, change the order, etc). You probably can't make them do it so that websites can't see the browser type, and you might not want to.

olliej5• 7 years ago

This is a completely unrelated aspect of the modern web. Fingerprinting is a giant mess of edgecases to manage. For all my feelings on Chrome’s privacy track record, this is an incredibly big improvement to security across the web. More specifically this change to cookie policy is a “fix an entire class of security bugs” change vs piecemeal fixes to individual instance of a bug class.

tptacek8• 7 years ago

Wow, if this works, this is basically the end of CSRF. Essentially: CSRF relies on an HTTP POST to VICTIM.COM triggered by HTML on EVIL.COM, and that request carrying cookies. Today, even though SameSite exists, the default --- SameSite=None --- maintains that longstanding status quo. But after the change, the Chrome default will be SameSite=Lax, and while EVIL.COM will still be able to trigger POSTs to VICTIM.COM, those requests will no longer carry cookies.

To get the cookies to work from EVIL.COM, VICTIM.COM's developers will have to explicitly set SameSite=None on their session cookies. Which nobody will do, because nobody sets SameSite at all today.

Better still: 99 out of 100 CSRF exploits (maybe 999 out of 1000) target endpoints for which SameSite=None isn't needed; they're cookies nobody ever uses cross-site to begin with. There are only limited cases where anyone needs the behavior to change, and those cases don't track the most sensitive cookies.

As a vulnerability researcher for whom exploitable bugs mostly exist to spark joy: good riddance to CSRF. It was a dumb bug class, and never, ever fun to exploit.

Lx1oG-AWb6h_ZG0• 7 years ago

Before you start emitting samesite=lax, be warned that webkit/safari iOS12 has a weird implementation: if you set the cookie in a POST method and redirect to a GET (like most default oauth explicit grant login flows), the cookie will not be sent: they consider POST pages as "unsafe". See https://bugs.webkit.org/show_bug.cgi?id=188165#c12 for more details.

Edit: it looks like people have found other issues since I last looked at this bug:

It's a serious issue affecting many common user flows, including the flow of visiting a website coming from a GMail link. If the user comes from GMail, it reaches the destination website without any cookies, thereby breaking functionalities that depend on session/login cookie and CSRF cookie. Only fix for now seems to be removing the Lax flag from cookies. (https://bugs.webkit.org/show_bug.cgi?id=188165#c47)

At this point, it looks like the safest approach is to only emit sameSite if the browser isn't safari.

mikewest3• 7 years ago

We did just clarify this in the spec: https://github.com/httpwg/http-extensions/commit/49bcb4fddb8.... Hopefully that, plus the tests we'll add in https://bugs.chromium.org/p/chromium/issues/detail?id=960375 will help other vendors align their behavior with developer expectations.

simonebrunozzi• 7 years ago

I read half of your comment, and thought: wow, this guy really explains things very well. Incredibly well. It's that simplicity and clearness that you only find in great teachers with very deep technical skills.

And then I saw your username... Ah, of course! :)

rob-olmos• 7 years ago

Is a SameSite=Strict cookie sent if VICTIM.COM does a redirect?

If so, it sounds like the next trick to follow would be a type of "redirect gadget" to get SameSite=Strict to be exploitable again. If so, maybe it's only the end of CSRFs without a gadget.

Eg of "redirect gadget", CSRF via VICTIM.COM/open-redirect?url=/update-password...

zzzzzzqzzzzzz2• 7 years ago

Not that any step towards additional privacy protections isn't a good thing, same for security. But Google has got to be one of the major contributors to the erosion of privacy.

How about chrome nagging to have you sign in? How about their very own ad networks?

techntoke3• 7 years ago

You mean like Firefox sync and Pocket? The so called founder of JavaScript was the CEO of Mozilla, and that is the biggest cause of erosion of privacy on the web.

zzzzzzqzzzzzz2• 7 years ago

Absolutely. I should have the option to use a browser, be it Firefox or Chrome, without unwanted integrations or 'features'.

I'd like a browser that just browses the internet and respects my privacy. But apparently that's too much to ask

akersten• 7 years ago

This is great - the `SameSite=lax` attribute is arguably how cookies should have worked in the first place, and I'm quite pleased that it's an existing RFC and not a proprietary change being done just in Chrome. Hopefully other browsers follow suit.

What worries me is the vague commitment to stop browser fingerprinting - not a lot of detail there and I'm fearful that useful features might be getting crippled. I don't think I'm as convinced that browser fingerprinting is as big of an issue as CSRF (prevented by the cookie changes here). Time will tell I suppose.

Ajedi322• 7 years ago

The reason this is related to browser fingerprinting is that cross-site cookies aren't _just_ used for CSRF, they're also a way to track users across sites.

With this change, developers will have to _explicitly_ declare when they're using cookies for that purpose (by setting SameSite=none) which makes it easier for browsers to identify cookies used for tracking and give users control over them.

niftich• 7 years ago

This is a continuation of a long arc of convergent work [1][2][3][4][5] by various people over several years; I've been following along [6].

The innovation of this proposal is to work towards the crossdomain cookie transmission being less insecure-by-default, by eventually making the current, limitless behavior opt-in.

This shifts the incentive of developers: presumably those whose sites require crossdomain acceptance of cookies will modify their sites accordingly, while those whose sites don't, or those who haven't thought about the issue will see fewer incidences of the most egregious POST-based CSRF.

[1] https://www.microsoft.com/en-us/research/publication/atlanti... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=795346 [3] https://github.com/mozmark/SameDomain-cookies/blob/master/sa... [4] http://homakov.blogspot.com/2013/02/rethinking-cookies-origi... [5] https://tools.ietf.org/html/draft-west-first-party-cookies-0... [6] https://news.ycombinator.com/item?id=13689697#13691022

driverdan• 7 years ago

The easiest way to improve cookie privacy is to block 3rd party cookies by default. Adding new polices is not the right solution. 3rd party cookies are completely unnecessary.

om23• 7 years ago

Safari's Intelligent Tracking Prevention effectively blocks third-party cookies, at least for resources that are used in a third-party context on multiple sites. This google Chrome proposal also does it, but provides a dead simple workaround for trackers by sending SameSite=None and Secure with the cookie.

user17843• 7 years ago

Let me guess: Google will tie the new proposal to a new Chrome setting which effectively identifies tracking cookies according to this new identifier, and will regularly purge them.

propogandist• 7 years ago

This will never happen. Google's entire ecosystem is built around advertising, so everything is an illusion of privacy. Things like 3rd party cookies will be the norm and Google won't block them, although firefox has started to head down that direction.

Chrome mobile, for example, can support add-ons and privacy features, but the risk to ad revenue is preventing them from making it available. Chrome being the default browser for Android means most people won't switch and they have >~80% marketshare.

fenwick67• 7 years ago

Why do cross-domain requests need cookies at all? Honest question, why couldn't we just stop sending them ever?

actimia• 7 years ago

At my company for example we run services on multiple domains that are all authenticated by a single backend. Could probably be solved by some re-architecturing, but changing cookie behaviour would definitly break existing sites.

sempron64• 7 years ago

Is there a timeline for this change?

Improving privacy and security on the web

Related Stories