5 ms·

Temporarily rolling back SameSite Cookie Changes

102 points by KarlKemp 7y ago

lol768 7y ago
Seems like a reasonable concession to make during these unprecedented times. Sites using CSRF tokens properly should be fine. Mozilla did the same for their TLS 1.0/TLS 1.1 change: https://hacks.mozilla.org/2020/02/its-the-boot-for-tls-1-0-and-tls-1-1/ https://hacks.mozilla.org/2020/02/its-the-boot-for-tls-1-0-a...
dmix 7y ago
The explainer of the changes are here: https://web.dev/samesite-cookies-explained/ https://web.dev/samesite-cookies-explained/
- danielmichaelni 7y ago
  Does this mean that if we use SameSite=Lax for our session cookies, we don't need to worry about CSRF attacks?
  - jacobparker 7y ago
    Mostly, if you opt in: https://caniuse.com/#feat=same-site-cookie-attribute https://caniuse.com/#feat=same-site-cookie-attribute . SameSite=Lax will still send cookies for some types of GET requests, depending on the complexity of your site and UX there are ways to be more protected (with SameSite=Strict, cookie pairs etc.) Once all browsers behave like Chrome is trying to (SameSite=Lax by default) we will have dramatically less CSRF on the web. Other browsers are likely to adopt this change eventually if Chrome sticks with it. You will at least need to consider users with out-of-date browsers for a while yet (and implement XSRF tokens and/or explicitly opt-in to Lax/whatever). The old behaviour will still (and always?) be around with SameSite=None. It has uses, but misuses could create CSRF vulnerabilities. There will still be CSRF problems on the web but it will get a lot rarer and, mercifully, not the default.
    - lonelappde 7y ago
      This API is a disaster. None is insecure, but Lax is private? Lax and Strict are adjectives. What are they even modifying? Not "SameSite"! They are referring to "SameSiteRestriction" or something. Why not align with CS of CSRF as AllowCrossSite, and values Always / OnUserRequest / Never ?
duxup 7y ago
I wonder how much impact this even would have had. But rolling it back is fine if they're going to go through with it later.
snomad 7y ago
While they may be rolling back at the browser level, if you have any role in administering a site, you should still consider turning them on. In php.ini, this is as easy as session.cookie_samesite = "Lax"
rooam-dev 7y ago
My question is how Chrome knows if it's a big impact or not? I assume it's based on metrics sent to google's servers. Can those be disabled?
- dotproto 7y ago
  Can't speak for other Chromies, but what's crossed my radar has been direct outreach from developers and bug reports.
oblib 7y ago
I just heard of this a couple weeks ago and almost got bit by it. I was reading the console.log while debugging some code with the Opera browser and it contained a message warning me they were going to implement it in just a few weeks. For me it had to do with delivering .js app code from one server that connected to a CouchDB server running on a different vps, so the impact would've resulted in users calling and me having no clue about why things were broken. I don't know how I missed hearing about it before but the CouchDB team had already done what was needed on their end. Finding out how to implement it was a bit difficult for me though, but I got lucky when someone brought it up on the CouchDB users email list and their message pointed me to what I needed to do. I generally just glance at those emails. I suppose I ought to bookmark web.dev and make a point to visit it. Thank you for sharing that link dmix.
SquareWheel 7y ago
This is appreciated. This change did break some things for me, and I've been scrambling to understand what SameSite cookies are and how this affects things.
- ninju 7y ago
  This site that does a good job of explaining then rationale behind the change https://web.dev/samesite-cookies-explained/ https://web.dev/samesite-cookies-explained/
  - SquareWheel 7y ago
    Thanks for the link! web.dev was the first resource I turned to, and it had some excellent articles on the topic. Though I'm now onto more complex topics like "cookie passing when submitting a form in a third-party iframe".
0az 7y ago
Amusingly, I was bit by this today because of some issues that required Cisco's secure email service: opened the attached HTML file, but couldn't log in, since they haven't added support for Same site. Found a workaround, but I'm glad they're doing this for the duration.
dugmartin 7y ago
We had quite a few old Rails 3 apps at work and had to create a gem to make sure this change didn’t break them - when they start rolling it back out it might be helpful for folks: https://github.com/concord-consortium/secure-samesite-cookies https://github.com/concord-consortium/secure-samesite-cookie...
ninju 7y ago
Everything I read about the original change gave me the impression that it's all backward compatible with earlier versions of Chrome. If you have already made the require changes there's no reason to roll anything back or undo do any work. Is my understanding correct?
- SquareWheel 7y ago
  That's right. Not unless you go back to extremely old versions of Chrome, which would not have understood the SameSite=None setting.

102 points by KarlKemp 7y ago

Seems like a reasonable concession to make during these unprecedented times. Sites using CSRF tokens properly should be fine. Mozilla did the same for their TLS 1.0/TLS 1.1 change: https://hacks.mozilla.org/2020/02/its-the-boot-for-tls-1-0-and-tls-1-1/ https://hacks.mozilla.org/2020/02/its-the-boot-for-tls-1-0-a...

dmix 7y ago

The explainer of the changes are here: https://web.dev/samesite-cookies-explained/ https://web.dev/samesite-cookies-explained/

danielmichaelni 7y ago
Does this mean that if we use SameSite=Lax for our session cookies, we don't need to worry about CSRF attacks?
- jacobparker 7y ago
  Mostly, if you opt in: https://caniuse.com/#feat=same-site-cookie-attribute https://caniuse.com/#feat=same-site-cookie-attribute . SameSite=Lax will still send cookies for some types of GET requests, depending on the complexity of your site and UX there are ways to be more protected (with SameSite=Strict, cookie pairs etc.) Once all browsers behave like Chrome is trying to (SameSite=Lax by default) we will have dramatically less CSRF on the web. Other browsers are likely to adopt this change eventually if Chrome sticks with it. You will at least need to consider users with out-of-date browsers for a while yet (and implement XSRF tokens and/or explicitly opt-in to Lax/whatever). The old behaviour will still (and always?) be around with SameSite=None. It has uses, but misuses could create CSRF vulnerabilities. There will still be CSRF problems on the web but it will get a lot rarer and, mercifully, not the default.
  - lonelappde 7y ago
    This API is a disaster. None is insecure, but Lax is private? Lax and Strict are adjectives. What are they even modifying? Not "SameSite"! They are referring to "SameSiteRestriction" or something. Why not align with CS of CSRF as AllowCrossSite, and values Always / OnUserRequest / Never ?

duxup 7y ago

I wonder how much impact this even would have had. But rolling it back is fine if they're going to go through with it later.

snomad 7y ago

While they may be rolling back at the browser level, if you have any role in administering a site, you should still consider turning them on. In php.ini, this is as easy as session.cookie_samesite = "Lax"

rooam-dev 7y ago

My question is how Chrome knows if it's a big impact or not? I assume it's based on metrics sent to google's servers. Can those be disabled?

dotproto 7y ago
Can't speak for other Chromies, but what's crossed my radar has been direct outreach from developers and bug reports.

oblib 7y ago

I just heard of this a couple weeks ago and almost got bit by it. I was reading the console.log while debugging some code with the Opera browser and it contained a message warning me they were going to implement it in just a few weeks. For me it had to do with delivering .js app code from one server that connected to a CouchDB server running on a different vps, so the impact would've resulted in users calling and me having no clue about why things were broken. I don't know how I missed hearing about it before but the CouchDB team had already done what was needed on their end. Finding out how to implement it was a bit difficult for me though, but I got lucky when someone brought it up on the CouchDB users email list and their message pointed me to what I needed to do. I generally just glance at those emails. I suppose I ought to bookmark web.dev and make a point to visit it. Thank you for sharing that link dmix.

SquareWheel 7y ago

This is appreciated. This change did break some things for me, and I've been scrambling to understand what SameSite cookies are and how this affects things.

ninju 7y ago
This site that does a good job of explaining then rationale behind the change https://web.dev/samesite-cookies-explained/ https://web.dev/samesite-cookies-explained/
- SquareWheel 7y ago
  Thanks for the link! web.dev was the first resource I turned to, and it had some excellent articles on the topic. Though I'm now onto more complex topics like "cookie passing when submitting a form in a third-party iframe".

0az 7y ago

Amusingly, I was bit by this today because of some issues that required Cisco's secure email service: opened the attached HTML file, but couldn't log in, since they haven't added support for Same site. Found a workaround, but I'm glad they're doing this for the duration.

dugmartin 7y ago

We had quite a few old Rails 3 apps at work and had to create a gem to make sure this change didn’t break them - when they start rolling it back out it might be helpful for folks: https://github.com/concord-consortium/secure-samesite-cookies https://github.com/concord-consortium/secure-samesite-cookie...

ninju 7y ago

Everything I read about the original change gave me the impression that it's all backward compatible with earlier versions of Chrome. If you have already made the require changes there's no reason to roll anything back or undo do any work. Is my understanding correct?

SquareWheel 7y ago
That's right. Not unless you go back to extremely old versions of Chrome, which would not have understood the SameSite=None setting.