Page MenuHomePhabricator

Central auth fails when using "site isolation" in Google Chrome and Chromium or "first-party isolation" in Firefox
Open, Needs TriagePublic

Description

If "site isolation" is turned on, or "first-party isolation", then Central auth seems to fail to properly log in the user.

Note that neither of these are turned on by default, but it is likely they will be in the future.

There are also a "strict site isolation" for Google Chrome.

Event Timeline

jeblad created this task.Aug 15 2018, 9:01 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 15 2018, 9:01 PM

What does "fail" mean? Is it outputting error messages? Or just failing to log you in?

Fail to log in. I've double checked in Firefox and there are no error messages in the browser. I would have been very surprised if there were any error messages, as that would imply a path between the isolated instances.

In Firefox it seems like subdomains are not isolated, only domains. That is central auth logs me in on enwiki if I log in at nowiki, but it does not log me in at meta.

jeblad updated the task description. (Show Details)Aug 16 2018, 9:50 AM
jeblad updated the task description. (Show Details)Aug 16 2018, 9:52 AM
Anomie added a subscriber: Anomie.Aug 16 2018, 5:40 PM

I'm not sure there's anything we can do here. The whole point of these features is to prevent setting/accessing cookies for other domains from JS or images, and that's exactly what CentralAuth needs to do. Anything we do to work around it seems likely to be blocked eventually.

The one thing that might not be blocked would be to have ext.centralauth.centralautologin.js try a CORS request to login.wikimedia.org to see if the user is logged in there, and if so either redirect the whole browser window or provide a link to do the same.

A CORS request to login.wikimedia.org would work, and it could provide necessary login info. There are several other methods too. One is to open an iframe and to use postMessage()to transfer login information. Another is to add a one time token to the url, and then check if someone else is logged in from the same IP-address, and then if one of those accept the one time token.

Still note that Cross-Origin Read Blocking (CORB) prevents the renderer process from receiving a cross-origin data resource unless CORS explicitly allow access to the resource. I have not checked but my guess is that login.wikimedia.org just add cookies to an image request, and does not use CORS properly. Fix CORS and I guess login works as-is.

A CORS request to login.wikimedia.org would work, and it could provide necessary login info.

Note one request would be insufficient. The current redirect-based process (via either <img> or <script>) uses five steps, implemented by SpecialCentralAutoLogin:

  1. A cacheable hit to the local wiki to begin the process. (/start)
  2. An anon-cacheable check to loginwiki that the user is actually logged in there, to an SUL account. (/checkLoggedIn)
  3. A hit to the local wiki to set up the local session. (/createSession)
  4. A hit to the loginwiki to validate the data. (/validateSession)
  5. A hit to the local wiki to set the cookies. (/setCookies)

Note caching in steps 1 and 2 is important to avoid overloading the app servers, see T56195 for details.

Other than potentially omitting step 1 entirely, I'd be wary of trying to reduce the number of steps without a full security re-review. I don't remember the details from 5 years ago, but reviewing some old notes it looks like the extra back-and-forth is intended to defend against attacks where an attacker does the first few steps and then gets the victim to complete the process resulting in the victim being logged in to an account controlled by the attacker.

One is to open an iframe and to use postMessage()to transfer login information.

Are you talking about having Special:UserLogin use a bunch of JS to post to every site? That would be a lot to do from an extension. And if iframes can so easily get around these "isolation" things, it seems reasonably likely the bad ad networks will jump on that and the browsers will have to block it.

Another is to add a one time token to the url, and then check if someone else is logged in from the same IP-address, and then if one of those accept the one time token.

That doesn't seem workable. At minimum it would mean starting to track who's logged in from each IP address and would break for various kinds of proxies. It's also not clear what URL you're talking about adding a token to or how it would prevent various attacks.

I have not checked but my guess is that login.wikimedia.org just add cookies to an image request, and does not use CORS properly. Fix CORS and I guess login works as-is.

The drawback with all of that is that it requires the user has JavaScript enabled, while the existing <img>-based mechanism doesn't. We'll likely wind up keeping the image-based mechanism for the cases where it works, and potentially update ext.centralauth.centralautologin.js with CORS requests (rather than using a <script> tag as it does now) once someone has time to test and write code for it.

  1. or 2. is probably the reason why unified login already fails a lot, but this task isn't about that.
  2. and 4. would probably fail without CORS, so CORS must be enabled already (using script-tags, that seems like a bad idea)
  3. fails because of CORB, check why, perhaps it is al that remains to make this work again

Site isolation isn't about blocking ads, it is about leaking information between instances. The call postMessage() is part of webmessaging. If you want to discuss JS, then sorry, I'm not into flamewars over languages.

If you don't believe one time tokens are workable, then that is your decission. Identification of sessions by one time tokens are although quite common.

Then fix whatever works or can be made to work in the future, because the present solution already fails.

jeblad renamed this task from Central auth fails when using "site isolation" in Google or "first-party isolation" in Firefox to Central auth fails when using "site isolation" in Google Chrome and Chromium or "first-party isolation" in Firefox.Aug 18 2018, 1:29 PM

I just tried it out (while looking into T231887) and this is weirdly asymmetric.

Assuming I have strict site isolation active on Chromium:

  1. If I only login on de.wikipedia.org, then I'm still not logged in on www.wikidata.org (as expected)
  2. If I only login on www.wikidata.org, then I'm automagically logged in on de.wikipedia.org!?

Shouldn't 1. and 2. be the same?

o.O