Cross-browser tracking vulnerability in Tor, Safari, Chrome, and Firefox

In this article, we introduce a scheme flooding vulnerability, explain how the exploit works across four major desktop browsers and show why it's a threat to anonymous browsing.

Last Update: August 2022

Exploiting custom protocol handlers for cross-browser tracking in Tor, Safari, Chrome and Firefox

DISCLAIMER: Fingerprint 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 there should be open discussions about such vulnerabilities to help internet browser providers fix them quickly. To help improve it, we have submitted bug reports to all affected browsers, created a live demo, and made a public source code repository available to all.

Test the vulnerability on our live demo site. Works on desktop browsers only.

In our research into anti-fraud techniques, we have discovered a vulnerability that allows websites to identify users reliably across different desktop browsers and link their identities together. The desktop versions of Tor Browser, Safari, Chrome, and Firefox are all affected.

We will refer to this vulnerability as scheme flooding, using custom URL schemes as an attack vector. The vulnerability uses information about installed apps on your computer to assign you a permanent unique identifier even if you switch browsers, use incognito mode, or use a VPN.

Why does this matter?

The scheme flooding vulnerability allows for third-party tracking across different browsers and thus violates privacy.

No cross-browser anonymity

Cross-browser anonymity is something that even a privacy-conscious internet user may take for granted. Tor Browser is known to offer the ultimate privacy protection. However, due to some websites' slow connection speed and performance issues, users may rely on less anonymous browsers for everyday surfing. They may use Safari, Firefox, Chrome, or Tor for sites where they want to stay anonymous. A website exploiting the scheme flooding vulnerability could create a stable and unique identifier to link those browsing identities.

All major browsers are affected, even if you are not a Tor Browser user. For example, it's possible to link your Safari visit to your Chrome visit, identify you uniquely and track you across the web.

Profiling based on installed apps

Additionally, the scheme flood vulnerability allows for targeted advertisement and user profiling without user consent. Your device's installed applications can reveal much about your occupation, habits, and age. For example, you will likely be a backend developer if there is a Python IDE or a PostgreSQL server on your computer.

Depending on the apps installed on a device, it may be possible for a website to identify individuals for more sinister purposes. For example, a website may be able to associate anonymous browsing history with a government or military official based on their installed applications.

Unknown impact on the web

This vulnerability has been possible for more than five years, and its actual impact is unknown. In a quick web search, we couldn't find any website actively exploiting it, but we still felt the need to report it as soon as possible.

How does it work? (technical overview)

Note: You may skip this section if you are not interested in the technical implementation details. The source code of the demo application is available on GitHub.

The scheme flooding vulnerability allows an attacker to determine your installed applications. By generating, a 32-bit cross-browser device identifier, a website can test for installation of 32 popular applications. On average, the identification process takes a few seconds and works across desktop Windows, Mac, and Linux operating systems.

While checking the presence of an application, browsers can use built-in custom URL scheme handlers. You can see this feature by entering skype:// in your browser address bar. If you have Skype installed, your browser will open a confirmation dialog that asks if you want to launch it. This feature is also known as deep linking and is widely used on mobile devices but is available within desktop browsers. In addition, any application that you install can register its scheme to allow other apps to open it.

An example of a custom URL scheme handler for Zoom

To detect the installation of an application, we can test an application's custom URL scheme and for the existence of a pop-up.

The following steps are required to make this vulnerability possible:

  1. Prepare a list of application URL schemes that you want to test. The list may depend on your goals. For example, if you're going to check for industry or interest-specific applications.
  2. Add a script on a website that will test each application from your list. The script will return an ordered array of boolean values: true if installed and false if not. 
  3. Use this array to generate a permanent cross-browser identifier.
  4. Optionally, use machine learning algorithms to guess your website visitors' occupation, interests, and age using installed application data.

The steps above may sound easy, but most browsers have safety mechanisms to prevent such exploits. Unfortunately, weaknesses in these safety mechanisms are what make this vulnerability possible. You can bypass it by combining CORS policies and browser window features.

The actual implementation of the exploit varies by browser. However, the basic concept is the same. It works by asking the browser to show a confirmation dialog in a pop-up window. Then the JavaScript code can detect a recently opened pop-up and the presence of an application based on that.

Let's walk through some of the browser differences.

Chrome

August 2022 Update: The Chromium bug-tracker for this is still an open, unresolved issue.

Of the four major browsers impacted, only Chrome developers appear to be aware of the scheme flooding vulnerability.

Additionally, only the Chrome browser had any form of scheme flood protection which presented a challenge to bypass. It prevents application launching unless a user gesture requests, like a mouse click. In addition, a global flag allows (or denies) websites to open applications, which becomes false after handling a custom URL scheme.

An example of how the Chrome browser protects against scheme flooding by requiring a user gesture

However, you can use Chrome extensions to reset this flag and bypass the scheme flood protection. By specification, extensions need to be able to open custom URLs, such as mailto: links, without confirmation dialogs. Unfortunately, the scheme flood protection conflicts with extension policies, so a loophole resets this flag every time any extension is triggered.

The built-in Chrome PDF Viewer is an extension that resets the scheme flood protection flag whenever your browser opens a PDF file. Opening a PDF file before opening a custom URL makes the exploit functional.

Firefox

August 2022 Update: This is still an unresolved issue for Firefox.

Firefox will show you an internal page with an error whenever you navigate an unknown URL scheme. This internal page has a different origin than any other website, so it is impossible to access it because of the Same-origin policy limitation. On the other hand, on a website with a known custom URL scheme, it will appear as about:blank, whose origin will be accessible from the current website.

An example of how you can check if an application is installed based on the origin URL

By opening a pop-up window with a custom URL scheme and checking if its document is available from JavaScript code, you can detect the application on a device.

Safari

Despite privacy being a main development focus for the Safari browser, it turned out to be the most accessible browser of the four to exploit. Safari doesn't have a scheme flood protection, allowing the exploit to enumerate all installed applications easily.

Safari uses the same-origin policy trick as the Firefox browser.

Tor Browser

August 2022 Update:There is now a fix in Tor Browser.You can read the original content below, but please refer to the patch for a fix. 

Tor Browser has confirmation dialogs disabled entirely as a privacy feature, ironically exposing a more damaging vulnerability for this particular exploit. Additionally, while the exploit runs in the background, it shows nothing, contrasting with other browsers that show pop-ups during the process. This oversight allows the exploit to check through installed applications without users realizing it.

Based on the Firefox source code, Tor Browser also used the same-origin policy trick here. But because Tor Browser does not show pop-ups, we used the same-origin policy trick with iframe elements instead.

By creating an iframe element with a custom URL scheme and checking if its document is available, you can check for application installation.

An example of how you can use an iframe element to check if an application is installed

Of the four browsers, the scheme flooding vulnerability takes the longest to run in Tor successfully. It takes the longest to run due to Tor Browser policies that take up to 10 seconds to check. Still, the exploit can work in the background and track you over a more extended browsing session. For example, if you left a Tor Browser window on a web page only for 4 minutes, it could be enough to expose your identity.

It's possible to remove the 10-second limitation by running each application test inside a user-triggered gesture. A fake captcha is an ideal candidate: 24 characters entered by a user makes it possible to reset that 10-second limitation 24 times in a row and enumerate 24 installed applications instantaneously.

Conclusion

The exact steps to make the scheme flooding vulnerability possible vary by browser, but the result is the same. In practice, malicious websites can obtain a unique array of bits associated with a visitor's identity.

Even with Tor Browser, this vulnerability tricks users into typing one character per application we want to test.

Until there is a fix for the vulnerability, the only way to have private browsing sessions not associated with your primary device is to use another device altogether.

By submitting these bug reports, writing this article, and building our demo application, we hope this vulnerability is fixed across all browsers as soon as possible.

If you enjoyed reading this article, consider joining our fully remote team to work on exciting research in online security.

Share this post