Page MenuHomePhabricator

Prepare CentralAuth (e.g. login.wikimedia.org) for requirement of SameSite=None cross-site cookies in Chrome
Closed, ResolvedPublic

Description

If we don't then most likely means people can no longer login to Wikipedia the normal way. Or they might be able to login manually, but won't be able to upload files to Commons, interact with Wikidata, send in-page feedback to talk pages on mediawiki.org or Meta-Wiki (like for VisualEditor), etc.

It would also mean when following cross-wiki projects like from Wikipedia to Wikidata/Commons/Wiktionary etc the user might not be auto-logged in.

Browser console (in Chrome)
A cookie associated with a cross-site resource at https://login.wikimedia.org/ was set
without the `SameSite` attribute. A future release of Chrome will only deliver cookies with
cross-site requests if they are set with `SameSite=None` and `Secure`.

You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

See also: Cookies default to SameSite=Lax (chromestatus.com)
See also: Reject insecure SameSite=None cookies (chromestatus.com)

  • (July 2019) This feature is available for testing in Chrome 76 for developers by enabling the cookies-without-same-site-must-be-secure flag. (ref)*

Timeline from https://www.chromium.org/updates/same-site:

  • Oct 2019: 50% of Chrome Beta users.
  • Feb 2020: Enforced for 1% of Chrome stable for 1 week.
  • March 2020: Enforced for 10%, 25%, and then 50% of Chrome stable
  • April 2020: Enforcement reduced to 0% for Chrome stable. It remains at 50% of Chrome Beta. (Reason: COVID19).
  • July 2020: Enforcement will we enabled for Chrome Stable in Chrome 84 on July 14. (news)

Related Objects

Event Timeline

Krinkle created this task.May 8 2020, 6:44 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 8 2020, 6:44 PM
Paladox added a subscriber: Paladox.May 8 2020, 7:31 PM
Krinkle renamed this task from Prepare login.wikimedia.org for deprecation of SameSite=None cross-site cookies in Chrome to Prepare login.wikimedia.org for removal of SameSite=None cross-site cookies in Chrome.May 8 2020, 9:38 PM
Krinkle renamed this task from Prepare login.wikimedia.org for removal of SameSite=None cross-site cookies in Chrome to Prepare login.wikimedia.org for requirement of SameSite=None cross-site cookies in Chrome.
Tgr added a subscriber: Tgr.May 10 2020, 1:39 PM

So I guess what's needed is:

  • add SameSite option to the cookie logic in WebResponse (we might as well default it to Lax which should be OK for most of our cookies)
  • add a SameSite option to CookieSessionProvider which it would pass to WebResponse
  • default that option to None in CentralAuthSessionProvider
Krinkle updated the task description. (Show Details)Jun 3 2020, 7:04 PM
  • Enforcement will we enabled for Chrome Stable in Chrome 84 on July 14. (news)
  • Firefox has also started enforcing this on their Betas meanwhile, and has scheduled release to Stable for Firefox 79 (July 28). (bug, schedule)
Krinkle renamed this task from Prepare login.wikimedia.org for requirement of SameSite=None cross-site cookies in Chrome to Prepare CentralAuth (e.g. login.wikimedia.org) for requirement of SameSite=None cross-site cookies in Chrome.Jun 14 2020, 3:47 PM
Nirmos added a subscriber: Nirmos.Jun 16 2020, 11:21 AM
Krinkle triaged this task as High priority.Jun 16 2020, 3:29 PM
Wiki13 added a subscriber: Wiki13.Jun 18 2020, 10:19 AM

Not only Chrome will have issues with, but Firefox too. As a matter of fact. I run pre-release versions of both browsers (I know, not recommended, but doesn't give much problems usually) and on both the login process is severly broken. Let's say I login on my homewiki (nlwiki). I will get a cookie for *.wikipedia,org as its the same domain. Same goes for wikis that are on *.wikimedia.org, because as far I understand a cookie will be set for that through login.wikimedia.org. Any other domains (Wikiquote, Wikinews, Wikidata, etc...) will not log you in and will require you to login normally, which can be a real pain if you are someone who works on a multitude of different projects (SWMT) and use 2FA. I can however note, that current release versions of these browsers and those based on it still work okayish (still requires me to force-reload page, when in the past that wasn't even neccesary).

Hopefully this gives you an idea on what kind of impact the changes by the browser makers have on the CentralAuth login

There are a bunch of browsers still in basic support that will break if we send SameSite=None. It will be necessary to check the User-Agent header before sending it.

I've been asked to work on this.

CDanis added a subscriber: CDanis.Jun 30 2020, 12:15 AM
ori added a subscriber: ori.Jun 30 2020, 5:02 AM

There are a bunch of browsers still in basic support that will break if we send SameSite=None. It will be necessary to check the User-Agent header before sending it.

In case it's useful, I saw an existing VCL implementation of the UA sniffing pseudocode from https://www.chromium.org/updates/same-site/incompatible-clients:
https://github.com/varnishcache/varnish-devicedetect/pull/45/commits/052e174b9d

PHP's setcookie() only added support for SameSite in PHP 7.3. It will be necessary to emulate it with header().

Krinkle updated the task description. (Show Details)Jul 1 2020, 2:14 AM

Testing on Firefox and Chromium shows that it is necessary to set SameSite=None on local session cookies in order for cross-site autologin to work. When a wiki is visited by a user who is logged in centrally but not locally, there is a four step process driven by redirects: central/checkLoggedIn -> local/createSession -> central/validateSession -> local/setCookies. Both browsers agree that a redirect from the central wiki to the local wiki is a cross-site request even though the top-level origin is the local wiki, so Lax cookies are not sent. Patching MW to make the local (and central) session cookies have SameSite=None causes autologin to work in both browsers.

Maybe there is a way to make it work by redesigning autologin, but that is beyond the scope of this task. My patch will just set SameSite=None on a sufficient number of cookies.

There is the question of how much we really care about the incompatible browsers, since the recommended solution for them (sending two cookies) is quite intrusive. I ran some queries in Turnilo. As a percentage of non-bot page views in the latest day:

  • Chrome 51-66: 0.3%
  • iOS 12: 2.5%
  • Safari on Mac OS 10.14: 0.4%

So it comes down to how much we care about supporting autologin for these browsers. Local login should continue to work regardless.

Local login should continue to work regardless.

Sorry, this was not correct. If local login cookies use SameSite=None, the incompatible browsers will drop the cookie, causing login to fail. I've installed Chromium 66 and observed this situation, and tested the fix.

Change 608993 had a related patch set uploaded (by Tim Starling; owner: Tim Starling):
[mediawiki/core@master] Support SameSite=None cookies

https://gerrit.wikimedia.org/r/c/mediawiki/core/ /608993

Change 609097 had a related patch set uploaded (by Tim Starling; owner: Tim Starling):
[mediawiki/extensions/CentralAuth@master] Add SameSite=None support

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/ /609097

Change 608993 merged by jenkins-bot:
[mediawiki/core@master] Support SameSite=None cookies

https://gerrit.wikimedia.org/r/608993

Change 609097 merged by jenkins-bot:
[mediawiki/extensions/CentralAuth@master] Add SameSite=None support

https://gerrit.wikimedia.org/r/609097

Change 610127 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[operations/mediawiki-config@master] Enable wgForceHTTPS and wgCookieSameSite='None' (Beta Cluster)

https://gerrit.wikimedia.org/r/610127

Will/Can the changes be backported to supported release branches?

Change 610147 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[operations/mediawiki-config@master] Enable wgForceHTTPS and wgCookieSameSite='None' (group0)

https://gerrit.wikimedia.org/r/610147

Change 610148 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[operations/mediawiki-config@master] Enable wgForceHTTPS and wgCookieSameSite='None' (group1)

https://gerrit.wikimedia.org/r/610148

Change 610149 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[operations/mediawiki-config@master] Enable wgForceHTTPS and wgCookieSameSite='None' (group2; all wikis)

https://gerrit.wikimedia.org/r/610149

Change 610127 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable wgForceHTTPS and wgCookieSameSite='None' (Beta Cluster)

https://gerrit.wikimedia.org/r/610127

Change 610147 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable wgForceHTTPS and wgCookieSameSite='None' (Phase 1)

https://gerrit.wikimedia.org/r/610147

Change 610148 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable wgForceHTTPS and wgCookieSameSite='None' (Phase 2)

https://gerrit.wikimedia.org/r/610148

Will/Can the changes be backported to supported release branches?

These changes take effect in less than 24 hours. Could it please be backported to supported release branches so non wikimedia wikis running the latest stable like Miraheze can apply the needed changes?

RhinosF1 moved this task from Radar to Miraheze-Linked on the User-RhinosF1 board.
Tgr added a comment.Jul 13 2020, 10:39 AM

Filed T257802: Backport SameSite fixes to all supported MediaWiki branches. CentralAuth is WMF-only / use-at-your-own-risk but I'd expect basic MediaWiki authentication to be affected for private wiki farms with shared functionality like images.

Change 612335 had a related patch set uploaded (by Paladox; owner: Tim Starling):
[mediawiki/core@REL1_34] Support SameSite=None cookies

https://gerrit.wikimedia.org/r/612335

Change 612336 had a related patch set uploaded (by Paladox; owner: Tim Starling):
[mediawiki/extensions/CentralAuth@REL1_34] Add SameSite=None support

https://gerrit.wikimedia.org/r/612336

Hi @Krinkle anything else needed from CPT for this?

Change 612395 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[operations/mediawiki-config@master] Enable wgForceHTTPS and wgCookieSameSite='None' (Phase 3)

https://gerrit.wikimedia.org/r/612395

Change 612396 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[operations/mediawiki-config@master] Enable wgForceHTTPS and wgCookieSameSite='None' (Phase 4)

https://gerrit.wikimedia.org/r/612396

Change 612395 merged by Krinkle:
[operations/mediawiki-config@master] Enable wgForceHTTPS and wgCookieSameSite='None' (Phase 3)

https://gerrit.wikimedia.org/r/612395

Change 612396 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable wgForceHTTPS and wgCookieSameSite='None' (Phase 4)

https://gerrit.wikimedia.org/r/612396

Change 612335 merged by jenkins-bot:
[mediawiki/core@REL1_34] Support SameSite=None cookies

https://gerrit.wikimedia.org/r/612335

Change 612336 merged by jenkins-bot:
[mediawiki/extensions/CentralAuth@REL1_34] Add SameSite=None support

https://gerrit.wikimedia.org/r/612336

Change 615843 had a related patch set uploaded (by Reedy; owner: Tim Starling):
[mediawiki/core@REL1_31] [WIP] Support SameSite=None cookies

https://gerrit.wikimedia.org/r/615843

Change 615849 had a related patch set uploaded (by Reedy; owner: Tim Starling):
[mediawiki/extensions/CentralAuth@REL1_31] Add SameSite=None support

https://gerrit.wikimedia.org/r/615849

Change 615843 merged by jenkins-bot:
[mediawiki/core@REL1_31] Support SameSite=None cookies

https://gerrit.wikimedia.org/r/615843

Change 615849 merged by jenkins-bot:
[mediawiki/extensions/CentralAuth@REL1_31] Add SameSite=None support

https://gerrit.wikimedia.org/r/615849