Temporarily rolling back SameSite Cookie Changes | Hacker News Reader

Temporarily rolling back SameSite Cookie Changes

blog.chromium.org

102 pointsKarlKemp17 comments

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-a...

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.

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"

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.

This site that does a good job of explaining then rationale behind the change

https://web.dev/samesite-cookies-explained/

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".

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

Does this mean that if we use SameSite=Lax for our session cookies, we don't need to worry about CSRF attacks?

Mostly, if you opt in: 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.

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 ?

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-cookie...

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.

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.

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?

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

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?

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

Reply on news.ycombinator.com