System fingerprinting like https://schemeflood.com/ use a slow variant, the bug enables tracking-services to fast list up all registered URL protocols. The problem on URL scheme fingerprinting is, that it will create a fingerprint for the system and not just the browser.

Tested on Windows 10 with Firefox 92 and Firefox 90.

The problem is that XMLHttpRequest will return different status codes dependent on the registration-state of the protocol or not.

Javascript code snippet:

var scheme = "spotify://dummy";

try {
var ajaxObj = new XMLHttpRequest()
ajaxObj.open("GET", scheme, false);
ajaxObj.send();
} catch (error) {
if (ajaxObj.status === 0) {
console.log("Protocol found: " + scheme);
} else { // regulary ajaxObj.status == 200
console.log("Protocol NOT found: " + scheme);
}
}

A fix would be to disallow XMLHttpRequest requests with protocols others than http, https, ...

(In reply to smolikraphael from comment #0)

A fix would be to disallow XMLHttpRequest requests with protocols others than http, https, ...

This seems like the kind of thing the fetch spec has something to say about. Anne, do you know if that is the case?

Yeah, as per https://fetch.spec.whatwg.org/#scheme-fetch anything other than about:/blob:/data:/file:/http:/https: ought to return a network error (which would result in status 0).

And that is the case for everything that invokes fetch, including XMLHttpRequest. The only thing that can handle other schemes is HTML's navigate algorithm, which only defers to fetch for certain schemes.

When fixing this we should make sure that HTML's <img>, CSS's background-image, fetch(), etc. do not have the same problem.

Kershaw, would you have time to look into this? (In case you see this while still OOO, please ignore until you are back. 😊)

I created a little example page to retrieve data from a client, for this project I found this bug. It checks the schemes dependent on the user agent to use different methods to check the schemes. (Firefox: this bug; chrome: focus loss method like https://schemeflood.com/ ; Edge a other method, that opens in the worst case each program; the last two will ask the user to start, because the bug is the single way, the user won't recognize). The found protocols will be displayed at the bottom. Here is the site. https://v2202108153726159664.quicksrv.de/

I now tested it with different systems:
Windows 10 the bug is there (tested with Firefox 90 and 92).
Android seems to list all schemes. (latest Firefox version and android 10)
Tor with Windows also won't work (I think because there are all prtotocol interactions restricted).
Ubuntu (21) and Firefox 89, the bug is also in.
Windows 8.1 and Firefox 78 and 90 the bug is also in.

This is just an update, I hope this is helpful for you.
I also have a question am I allowed to publish the bug, or is there any limitation in concerne with the bounty (if it is even relevant)?

(In reply to smolikraphael from comment #3)

I also have a question am I allowed to publish the bug, or is there any limitation in concerne with the bounty (if it is even relevant)?

Passing this question to Tom explicitly...

(In reply to smolikraphael from comment #3)

I also have a question am I allowed to publish the bug, or is there any limitation in concerne with the bounty (if it is even relevant)?

From a general security policy point of view, we would appreciate the opportunity to address the issue before it is published and some notice about when it will be published if so. From a Bug Bounty point of view, if a bug is made public before the issue is fixed, we generally look at the time that passed and events that occurred between reporting and publishing, and try to judge if the disclosure aligned with general industry best practices or not.

Jens, do you know who might be available to fix this soon? Thanks.

I guess we need to tweak the fix for bug 716491 a bit.

Thanks for taking this, Olli.

Noticed similar issue with the blob uri, so fixed that in this patch too.
Tests are in the next patch.

InitiateFetch() call a bit later handles the marking for some other error cases.

Depends on D130201

mark XHR load being an error load when send() fails, r=kershaw
https://hg.mozilla.org/integration/autoland/rev/b735ff2a23fd47ea0f2425f119e4f961e5cf8e5b
https://hg.mozilla.org/mozilla-central/rev/b735ff2a23fd

The patch landed in nightly and beta is affected.
:smaug, 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.

freddy, do you think we should uplift this?

The patch seems simple and I'm leaning towads yes.

Hi Dragana, smaug is not here the entire week, could you please request uplift?

I can do it :)

Comment on attachment 9248919 [details]
Bug 1723281, mark XHR load being an error load when send() fails, r=kershaw

Beta/Release Uplift Approval Request

• User impact if declined: Exposing registered URL schemes to web sites
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: So there is a testcase attached to the bug, but that hasn't landed. I wanted to wait a bit with that. Though, I guess the issue is known given the public web site.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): this should be low risk, because it is just tweaking an error case.
• String changes made/needed:

Comment on attachment 9248919 [details]
Bug 1723281, mark XHR load being an error load when send() fails, r=kershaw

Approved for 95 beta 8, thanks.

Hello! Can someone help to give some steps in order to reproduce and verify this manually?

I'm not sure what to do here, I loaded the javascript snippet from comment 0 in an affected build on https://playcode.io giving a Protocol NOT found: spotify://dummy console message and on a fixed build is giving a Protocol found: spotify://dummy console message, but I'm not sure that this is the right way.

Also, comment 17 is statting that a test case should be uploaded in near future. Thank you!

This ended up landing for 95.0b9.
https://hg.mozilla.org/releases/mozilla-beta/rev/18e4cff6fe01

Comment on attachment 9248919 [details]
Bug 1723281, mark XHR load being an error load when send() fails, r=kershaw

Approved for 91.4esr also.

https://hg.mozilla.org/releases/mozilla-esr91/rev/3eef2fe29d57

Hello! Can you please help me with some steps to manually reproduce/ verify this issue? Thank you in advance,

See the testcase, which I didn't land yet. I think I could land it now.

add a test for unknown scheme and post on blob uri, r=kershaw
https://hg.mozilla.org/integration/autoland/rev/326d58edc42519a7ed9079d7b53c2f353630f122
https://hg.mozilla.org/mozilla-central/rev/326d58edc425

We will be crediting you in the security advisories for our upcoming release of Firefox 95 as "smolikraphael".
Please respond to this needinfo request, if you wish to be credited differently (or not at all).

The name would be ok, Raphael Smolik would be better.

Advisory text changed. Thank you :)

Since we were not able to reproduce the issue, we are removing the qe+ flag, but if any additional information is added and QA is needed, please add again the qe+ flag.