By probing for installed apps with custom URL schemes, it’s possible to build a 32-bit unique fingerprint
FingerprintJS, maker of a browser-fingerprinting library for fraud prevention, on Thursday said it has identified a more dubious fingerprinting technique capable of generating a consistent identifier across different desktop browsers, including the Tor Browser.
That means, for example, if you browse the web using Safari, Firefox, or Chrome for some websites, and use the Tor browser to anonymously view others, there is a possibility someone could link your browser histories across all those sessions using a unique identifier, potentially deanonymize you, and track you around the web.
Doing this is non-trivial, it can be very inaccurate or unreliable, and so this is more of a heads up than anything else.
Konstantin Darutkin, senior software engineer at FingerprintJS, said in a blog post that the company has dubbed the privacy vulnerability “scheme flooding.” The name refers to abusing custom URL schemes, which make web links like “skype://” or “slack://” prompt the browser to open the associated application.
“The scheme flooding vulnerability allows an attacker to determine which applications you have installed,” explains Darutkin. “In order to generate a 32-bit cross-browser device identifier, a website can test a list of 32 popular applications and check if each is installed or not.”
Visiting the schemeflood.com site using a desktop (not mobile) browser and clicking on the demo will generate a flood of custom URL scheme requests using a pre-populated list of likely apps. A browser user would typically see a pop-up permission modal window that says something like, “Open Slack.app? A website wants to open this application. [canel] [Open Slack.app].”
But in this case, the demo script just cancels if the app is present or reads the error as confirmation of the app’s absence. It then displays the icon of the requested app if found, and moves on to its next query.
The script uses each app result as a bit to calculate the identifier. The fact that the identifier remains consistent across different browsers means that cross-browser tracking is possible, which violates privacy expectations.
The technique has been successfully tested on Chrome 90 (Windows 10, macOS Big Sur), Firefox 88.0.1 (Ubuntu 20.04, Windows 10, macOS Big Sur), Safari 14.1 (macOS Big Sur), Tor Browser 10.0.16 (Ubuntu 20.04, Windows 10, macOS Big Sur), Brave 1.24.84 (Windows 10, macOS Big Sur), Yandex Browser 21.3.0 (Windows 10, macOS Big Sur), and Microsoft Edge 90 (Windows 10, macOS Big Sur). Opera was not tested.
The Register initially could not get a result from Safari on macOS Big Sur because the test failed to complete. Ironically, given what’s going on in the Epic v. Apple trial at the moment, the Safari test froze when it could not find “com.epicgames.launcher://test”. But after clearing cookies and storage in Safari, we did manage to run the demo PoC and generate consistent fingerprint.
There have been some reports of inconsistent results and Darutkin has acknowledged that browser settings/flags, slow hardware or VMs, a slow internet connection, or user gestures during the PoC demo may skew the app count.
The various affected browsers should defend against scheme flooding but they don’t. “Weaknesses in these safety mechanisms are what makes this vulnerability possible,” explains Darutkin. “A combination of CORS policies and browser window features can be used to bypass it.”
For example, Chrome, alone among the major browsers, has implemented scheme flood protection that requires user interaction to launch a custom scheme resource. However, Chrome extensions aren’t bound by this policy because they need to be able to open custom URLs like “mailto://” links without interaction. So opening a PDF file with the built-in Chrome PDF Viewer extension resets the scheme flood prevention flag and enables the abusive app count.
The issue has been reported to the Chromium team which is currently looking at ways to address the problem.
In Firefox and Safari, scheme flooding works because the browser loads different internal pages depending upon whether the requested app is present or absent, which is all the information needed for that bit in the 32-bit app-count identifier. The situation is similar for the Tor browser, which is based on Firefox code, but requires the use of iframe elements to check app presence – and also time. It can take minutes to fingerprint a user.
As far as browser fingerprinting goes, counting apps isn’t necessary when visiting a website can reveal a large number of software and hardware characteristics. But browser makers should address scheme flooding nonetheless.
FingerprintingJS includes this disclaimer with Darutkin’s blog post to clarify that the sort of fingerprinting enabled by its JavaScript library is not the same as the fingerprinting made possible with the scheme flooding vulnerability:
“FingerprintJS does not use this vulnerability in our products and does not provide third-party tracking services. We focus on stopping fraud and support modern privacy trends for removing third-party tracking entirely. We believe that vulnerabilities like this one should be discussed in the open to help browsers fix them as quickly as possible.”
Source: https://www.theregister.com/2021/05/14/browser_fingerprinting_flaw/?&web_view=true
