From https://evercookie.0x41.link/xhrpreflight/

Interesting take aways:
 - On the majority of browsers clearing an entire browser cache doesn't fix this ... you have to additionally restart the browser process.</li>
 - Tor Browser 'new identity' option fails and user can be corellated with previously used identities.

How this POC works :

 - User visits e.g. https://evercookie.0x41.link/xhrpreflight/.
 - A JS script generates a number of XHRs in order to set a randomly generated ID in browsers' XHR preflight cache
 - Another JS script maps out the previously injected ID from the browsers XHR preflight...
 - ID is displayed to the user (this can be used to set the tracking cookie)

This issue was filed in Tor Browser's HackerOne.

I actually couldn't quite get the POC to work, but it seems like it could. If this is the preflight cache it only ever gets fully cleared upon destruction (shutdown.) We should call it in other circumstances also...

(In reply to Tom Ritter [:tjr] (ni? for response to sec-[advisories/bounties/ratings/cves]) from comment #0)

From https://evercookie.0x41.link/xhrpreflight/
[...]
I actually couldn't quite get the POC to work, but it seems like it could. If this is the preflight cache it only ever gets fully cleared upon destruction (shutdown.) We should call it in other circumstances also...

It's working in Tor Browser (based on 78.9.0esr). I agree that this looks like the preflight cache, and Tor Browser isn't clearing that in its New Identity functionality. IIUC, for this POC, the server-side is allowing cross-origin requests that include a x-set request header, and rejecting all other cross-origin requests. The unique ID is composed of 8 randomly selected characters in [0-9a-f], then sorted. In the ID generation phase, the client generates an ID and then iterates over the characters in the ID and fetches them individually as the resources (/0, /1, etc.) with x-set included as a request header - this primes the cache only with characters in the ID. In the recovery phase, the script probes the preflight cache for every character by iterating over every possible character and requesting it as the resource again - success if a cached preflight entry is returned, thus allowing the request to go through, and error if the request goes out to the server (without a x-set header - not indicated in the preflight).

I'd be happy with either an observer of content.cors.disable (similar to security.OCSP.enabled) that clears/invalidates the cache, or a hook in the site data sanitizer? The latter may be more useful for Firefox users.

Let's see if the Anti-Tracking team is willing to take this as networking is oversubscribed.

I suspect this this is a more general problem by the way. While we now partition most caches, including the CORS preflight cache in question here, I don't think we actively clear all of them when the user wishes to remove state.

See also bug 1696632 which is very similar.

(In reply to Anne (:annevk) from comment #3)

I suspect this this is a more general problem by the way. While we now partition most caches, including the CORS preflight cache in question here, I don't think we actively clear all of them when the user wishes to remove state.

See also bug 1696632 which is very similar.

Yes, that is true, historically Tor Browser has jumped through a few kludgy hoops as a way of working around this:
https://gitlab.torproject.org/tpo/applications/torbutton/-/blob/master/chrome/content/torbutton.js#L575

I wouldn't be surprised if there are other caches we are missing, though.

I put it on our triage list for tomorrow :)

Steve, can you try to verify this is an issue with clearing only in Firefox?

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

Steve, can you try to verify this is an issue with clearing only in Firefox?

I tested this and verified that we do at least partition this cache, and can reproduce the POC: any approach to clearing data from the UI doesn't impact the site's ability to recover the ID.

We should aim to fix this alongside our other site data management issues, which doesn't need to be a security bug. However, we should keep this hidden due to the impact to Tor Browser's New Identity functionality

(In reply to Steven Englehardt [:englehardt] from comment #7)

We should aim to fix this alongside our other site data management issues, which doesn't need to be a security bug. However, we should keep this hidden due to the impact to Tor Browser's New Identity functionality

Okay, so this sounds like it's not a priority for you. Do you have a recommended approach that we can (potentially) uplift? From comment #1:

I'd be happy with either an observer of content.cors.disable (similar to security.OCSP.enabled) that clears/invalidates the cache, or a hook in the site data sanitizer? The latter may be more useful for Firefox users.

Obviously, I'd prefer inheriting a fix instead of writing it, if that's feasible in the short-term.

Paul do you have any thoughts on Comment 8?

(In reply to Tom Ritter [:tjr] (OOTO, back June 28) from comment #9)

Paul do you have any thoughts on Comment 8?

In case it helps, I landed https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/9c9884c27d5a1ee93dde9d78eda6df5707e816f8 as a quick-fix, tying it to |browser:purge-session-history|.

(With a small fix https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/0f2ac709c04851627d75a7eb9ba32a4ecf7debf7)

I'm not sure if you'd take this for uplift, or if you want to go another route.

(In reply to Matthew Finkel [:sysrqb] from comment #10)

In case it helps, I landed https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/9c9884c27d5a1ee93dde9d78eda6df5707e816f8 as a quick-fix, tying it to |browser:purge-session-history|.
(With a small fix https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/0f2ac709c04851627d75a7eb9ba32a4ecf7debf7)
I'm not sure if you'd take this for uplift, or if you want to go another route.

Matthew, does that mean we can make this bug public now?

(In reply to Matthew Finkel [:sysrqb] from comment #10)

I'm not sure if you'd take this for uplift, or if you want to go another route.

Thanks! I'll take a look at your patch. We might add a separate cleaner in ClearDataService for it.

(In reply to Ethan Tseng [:ethan] from comment #11)

(In reply to Matthew Finkel [:sysrqb] from comment #10)

In case it helps, I landed https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/9c9884c27d5a1ee93dde9d78eda6df5707e816f8 as a quick-fix, tying it to |browser:purge-session-history|.
(With a small fix https://gitlab.torproject.org/tpo/applications/tor-browser/-/commit/0f2ac709c04851627d75a7eb9ba32a4ecf7debf7)
I'm not sure if you'd take this for uplift, or if you want to go another route.

Matthew, does that mean we can make this bug public now?

Ethan, thanks for asking. Let's keep it private for a few more days. We just released Tor Browser with this fix today, so this bug can become public at the beginning of next week.

Added PreflightCacheCleaner. r=necko-reviewers,johannh,dragana
https://hg.mozilla.org/integration/autoland/rev/593f4cfcf41659c64080335f7d1b1c063f31c0dc
https://hg.mozilla.org/mozilla-central/rev/593f4cfcf416

Is this something we should consider uplifting to 91 for the next ESR?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #16)

Is this something we should consider uplifting to 91 for the next ESR?

FWIW, I'd appreciate that (at some point during the 91esr cycle) so I can drop my downstream patch. I don't see much harm in uplifting it sooner, but that's pbz's call.

Maybe we can do an ESR uplift once this had some bake time in 92 beta?

The patch landed in nightly and beta is affected.
:pbz, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Hi Paul, is this ready for an ESR91 approval request?

Yes, I think we should uplift to ESR soon. However, in Bug 1721084 we've discovered that we're over-clearing some cleaners, even for automated clearing by websites or the PurgeTrackerService. This should be addressed before uplifting. I've submitted a patch for review that specifically fixes it for the PreflightCacheCleaner. I'll update you once I have feedback from Johann.

Comment on attachment 9237072 [details]
Bug 1704110 - Only clear the preflight cache on user request. r=johannh!

Revision D123134 was moved to bug 1727146. Setting attachment 9237072 [details] to obsolete.

Comment on attachment 9230090 [details]
Bug 1704110 - Added PreflightCacheCleaner. r=johannh!,#necko-reviewers

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Requested by Tor, see https://bugzilla.mozilla.org/show_bug.cgi?id=1704110#c17

NOTE: Should be uplifted along with the fix-up here: https://phabricator.services.mozilla.com/D123134 which is currently in 93.

• User impact if declined: Sites can use the preflight cache to set an in-memory supercookie, which users can't clear. This can be used for fingerprinting purposes.
  Also see https://bugzilla.mozilla.org/show_bug.cgi?id=1704110#c0
• Fix Landed on Version: 92
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): The base patch had a cycle of bake time in 92. No reported regressions. Has an integration test.
  Medium risk, because the code change isn't trivial and updates some interfaces.
• String or UUID changes made by this patch: none

Comment on attachment 9230090 [details]
Bug 1704110 - Added PreflightCacheCleaner. r=johannh!,#necko-reviewers

Approved for 91.1esr.

https://hg.mozilla.org/releases/mozilla-esr91/rev/f720fe89d32e