Open Bug 1696095 Opened 3 years ago Updated 2 years ago

Wikipedia SSO auto-login broken by state partitioning

Categories

(Core :: Privacy: Anti-Tracking, defect, P3)

Firefox 86
defect

Tracking

()

People

(Reporter: mozbugs, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

I am filing a bug about a site broken by the new storage access policies as advised by the section "report broken sites" on https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Privacy/Storage_access_policy#storage_access_grants

  • Log in to meta.wikimedia.org using your Wikipedia password
  • Network log shows three-stage session creation with most of our 2LDs including wikipedia.org, using 1x1 images. For example meta.wikimedia.org requests en.wikipedia.org/.../start, which then redirects to login.wikimedia.org/.../checkLoggedIn, which then redirects to en.wikipedia.org/.../createSession, but the third request does not send cookies which were set in the Set-Cookie headers of the first request.
  • Go to en.wikipedia.org, observe you are not logged in, due to the lack of session cookies set by the meta.wikimedia.org origin.
  • Click "log in". This initiates an explicit, scripted handshake with login.wikimedia.org. However the previously stored cookies for login.wikimedia.org are not sent with this request, and so automatic login is impossible.

Actual results:

As described above.

Expected results:

Please whitelist the following domains for legacy first-party cookie sharing:

  • wikipedia.org
  • wikimedia.org
  • wiktionary.org
  • wikibooks.org
  • wikiquote.org
  • wikisource.org
  • wikinews.org
  • wikiversity.org
  • mediawiki.org
  • wikivoyage.org

Please advise on the correct way forward for rearchitecting our SSO system.

Is it necessary for the user to interact with an iframe served by the central domain every time they wish to log in to a new registrable domain, as would seem to be implied by the requirement that requestStorageAccess() be initiated by a "user gesture", as documented at https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess ?

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → DOM: Security
Product: Firefox → Core
Component: DOM: Security → Privacy: Anti-Tracking

Hey, thank you for reaching out.

So, to be clear, in your case "broken" means that there is no automatic sharing of credentials across different domains, but otherwise logins on the individual sites with the same credentials work fine?

Your SSO seems to work slightly different than it does with the more common model of having an independent OAuth provider for otherwise unrelated sites. In your scenario, you assume that the user is comfortable with sharing login state between, say, wikipedia.org and wikivoyage.org implicitly, without requiring additional consent, because it's clear that these are related entities. That assumption is probably true, but I have to say that gaming the cross-origin boundary like this violates user expectations in various ways, for example when trying to clear cookies.

Implicit sharing of cross-site cookies isn't really a scenario we'd want to support, and the Storage Access API helps make the login model more explicit to users. So, yes, for that to work you could have an iframe for meta.wikimedia.org that will relay the auth state to the top-level site when the user clicks a "login" button. Alternatively, you could have a top-level navigation or popup to meta.wikimedia.org that will redirect to the site that needs the credentials.

Please whitelist the following domains for legacy first-party cookie sharing:

This isn't possible because there is no allow-list mechanism for state partitioning.

Generally I wouldn't consider this behavior a bug on our end and rather desired behavior, but please let me know if I misunderstood something.

I assume that this isn't broken on Firefox Release with "Standard" configurations, but only in "Strict" mode?

(In reply to Tim Starling from comment #0)

Is it necessary for the user to interact with an iframe served by the central domain every time they wish to log in to a new registrable domain, as would seem to be implied by the requirement that requestStorageAccess() be initiated by a "user gesture", as documented at https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess ?

Yes that's correct. Interaction with the embedded frame is a requirement to calling requestStorageAccess.

Implicit sharing of cross-site cookies isn't really a scenario we'd want to support

That is certainly true in general, but I have been thinking that it might be useful to allow such sharing between domains that (per their SSL cert) belong to the same organization. Is the concern that this would not be sufficiently transparent to users?

(In reply to Johann Hofmann [:johannh] from comment #2)

I assume that this isn't broken on Firefox Release with "Standard" configurations, but only in "Strict" mode?

Yes, I have now confirmed that this does not affect a default Firefox installation, you have to enable "strict" mode under Enhanced Tracking Protection in preferences. And then, it is possible to restore cross-domain login by disabling ETP for the site via the shield icon. So we're not quite in the emergency situation I thought we were in when I filed this bug yesterday.

So, to be clear, in your case "broken" means that there is no automatic sharing of credentials across different domains, but otherwise logins on the individual sites with the same credentials work fine?

Essentially, yes. With the affected configuration, to log in to two registrable domains, you need to enter your password twice. Some power users will routinely log in to ~10 registrable domains in a single session. Re-entering their password (and usually TOTP token) so many times would be a nuisance, but we can provide advice on appropriate Firefox configuration for them.

Your SSO seems to work slightly different than it does with the more common model of having an independent OAuth provider for otherwise unrelated sites. In your scenario, you assume that the user is comfortable with sharing login state between, say, wikipedia.org and wikivoyage.org implicitly, without requiring additional consent, because it's clear that these are related entities.

As Daniel points out, the TLS certificate makes it pretty clear that they are related entities. Actually, all our wikis are served out of the same IP address, and the TLS certificate is shared, with domains listed as subjectAltNames. So there's definitely no privacy boundary between them. I think the main reason for using different registrable domains is because you end up with shorter URLs.

That assumption is probably true, but I have to say that gaming the cross-origin boundary like this violates user expectations in various ways, for example when trying to clear cookies.

Yes, log out is quite complex in this model, you can't just clear your cookies for the current domain and expect to be logged out. Also it breaks WebAuthn ( bug report ). The system was designed in 2013 with the aim of making SSO be as seamless as possible for the user, and we took advantage of the lack of privacy protection in all major browsers at that time.

Implicit sharing of cross-site cookies isn't really a scenario we'd want to support, and the Storage Access API helps make the login model more explicit to users. So, yes, for that to work you could have an iframe for meta.wikimedia.org that will relay the auth state to the top-level site when the user clicks a "login" button. Alternatively, you could have a top-level navigation or popup to meta.wikimedia.org that will redirect to the site that needs the credentials.

I think top-level navigation to login.wikimedia.org is reasonable in terms of UX, similar to how YouTube shares state with Google. But there are a lot of details to sort out. We're talking about scheduling this project in the annual plan for next fiscal year, maybe with completion by the end of the calendar year.

This isn't possible because there is no allow-list mechanism for state partitioning.

Hypothetically, if a patch implementing an allow-list appeared in your Phabricator, do you think it would be approved?

I see that Mozilla already has a concept of sets of co-owned domains exempt from tracking protection: https://github.com/mozilla-services/shavar-prod-lists

"The Entity list is used to allow third-party subresources that are wholly owned by the same company that owns the top-level website that the user is visiting. For example, if abcd.com owns efgh.com and efgh.com is on the blocklist, it will not be blocked on abcd.com. Instead, efgh.com will be treated as first party on abcd.com, since the same company owns both."

Wikimedia is not on this list. So one option to resolve the bug is to respect the entity list when doing state partitioning, and for us to get on it.

Severity: -- → S3
Priority: -- → P3

Sorry for the delay :)

Essentially, yes. With the affected configuration, to log in to two registrable domains, you need to enter your password twice. Some power users will routinely log in to ~10 registrable domains in a single session. Re-entering their password (and usually TOTP token) so many times would be a nuisance, but we can provide advice on appropriate Firefox configuration for them.

For power users it's probably fine to tell them to disable protections for that site using the shield menu. A bit inconvenient for the general population but I would assume that most Wikipedia contributors aren't greatly affected by this.

Hypothetically, if a patch implementing an allow-list appeared in your Phabricator, do you think it would be approved?

While I appreciate the intent, this is not a matter of implementation difficulty for us. Having an allow-list mechanism is easy from a policy standpoint when you're already operating on a basis of block lists anyway, like the "old" ETP does. It's a different question for protections that treat all parties equally by design. We are currently discussing this internally and I'll keep you posted.

Rest assured that "associated domains" is a common problem with all major browsers adding restrictions to third party cookies, and there are other discussions and proposals in the privacy community that we're looking at.

If you ask me I still think it's a good idea to adopt a different authentication flow for your site. I understand that this is a big task for you, and I'm happy to advise on the different browser-side privacy restrictions and APIs that you might encounter along the way.

Wikimedia is not on this list. So one option to resolve the bug is to respect the entity list when doing state partitioning, and for us to get on it.

Yeah, as mentioned, we're not using this list for State Partitioning on purpose right now.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Wikipedia SSO broken by storage access policy → Wikipedia SSO auto-login broken by storage access policy
Summary: Wikipedia SSO auto-login broken by storage access policy → Wikipedia SSO auto-login broken by state partitioning
You need to log in before you can comment on or make changes to this bug.