Supercookie uses favicons to assign a unique identifier to website visitors.
Unlike traditional tracking methods, this ID can be stored almost persistently and cannot be easily cleared by the user.
The tracking method works even in the browser's incognito mode and is not cleared by flushing the cache, closing the browser or restarting the system, using a VPN or installing AdBlockers. 🍿 Live demo.
- Paper by Scientists at University of Illinois, Chicago: www.cs.uic.edu
- Article by heise: heise.de
This repository is for educational and demonstration purposes only!
The demo of "supercookie" as well as the publication of the source code of this repository is intended to draw attention to the problem of tracking possibilities using favicons.
requirements:
Docker daemon
- Clone repository
git clone https://github.com/jonasstrehle/supercookie- Update .env file in supercookie/server/.env
HOST_MAIN=yourdomain.com #or localhost:10080
PORT_MAIN=10080
HOST_DEMO=demo.yourdomain.com #or localhost:10081
PORT_DEMO=10081- Run container
cd supercookie/server
docker-compose up-> Webserver will be running at https://yourdomain.com
requirements:
- Clone repository
git clone https://github.com/jonasstrehle/supercookie- Update .env file in supercookie/server/.env
HOST_MAIN=localhost:10080
PORT_MAIN=10080
HOST_DEMO=localhost:10081
PORT_DEMO=10081- Run service
cd supercookie/server
node main.js-> Webserver will be running at http://localhost:10080
Workwise of supercookie
Modern browsers offer a wide range of features to improve and simplify the user experience. One of these features are the so-called favicons: A favicon is a small (usually 16×16 or 32×32 pixels) logo used by web browsers to brand a website in a recognizable way. Favicons are usually shown by most browsers in the address bar and next to the page's name in a list of bookmarks.
To serve a favicon on their website, a developer has to include an attribute in the webpage’s header. If this tag does exist, the browser requests the icon from the predefined source and if the server response contains an valid icon file that can be properly rendered this icon is displayed by the browser. In any other case, a blank favicon is shown.
<link rel="icon" href="/favicon.ico" type="image/x-icon">The favicons must be made very easily accessible by the browser. Therefore, they are cached in a separate local database on the system, called the favicon cache (F-Cache). A F-Cache data entries includes the visited URL (subdomain, domain, route, URL paramter), the favicon ID and the time to live (TTL). While this provides web developers the ability to delineate parts of their website using a wide variety of icons for individual routes and subdomains, it also leads to a possible tracking scenario.
When a user visits a website, the browser checks if a favicon is needed by looking up the source of the shortcut icon link reference of the requested webpage. The browser initialy checks the local F-cache for an entry containing the URL of the active website. If a favicon entry exists, the icon will be loaded from the cache and then displayed. However, if there is no entry, for example because no favicon has ever been loaded under this particular domain, or the data in the cache is out of date, the browser makes a GET request to the server to load the site's favicon.
In the article a possible threat model is explained that allows to assign a unique identifier to each browser in order to draw conclusions about the user and to be able to identify this user even in case of applied anti-fingerprint measures, such as the use of a VPN, deletion of cookies, deletion of the browser cache or manipulation of the client header information.
A web server can draw conclusions about whether a browser has already loaded a favicon or not: So when the browser requests a web page, if the favicon is not in the local F-cache, another request for the favicon is made. If the icon already exists in the F-Cache, no further request is sent. By combining the state of delivered and not delivered favicons for specific URL paths for a browser, a unique pattern (identification number) can be assigned to the client. When the website is reloaded, the web server can reconstruct the identification number with the network requests sent by the client for the missing favicons and thus identify the browser.
conventional cookies |
supercookie |
|
|---|---|---|
| Identification accuracy | - | 100% |
| Incognito / Private mode detection | ❌ | ✅ |
| Persistent after flushed website cache and cookies | ❌ | ✅ |
| Identify multiple windows | ❌ | ✅ |
| Working with Anti-Tracking SW | ❌ | ✅ |
It looks like all top browsers ( Chrome,
Firefox,
Safari,
Edge) are vulnerable to this attack scenario.
Mobile browsers are also affected.
Browser |
Windows |
MacOS |
Linux |
iOS |
Android |
|---|---|---|---|---|---|
| Chrome (v 87.0) | ✅ | ✅ | ✅ | ✅ | ✅ |
| Safari (v 14.0) | - | ✅ | - | ✅ | - |
| Edge (v 87.0) | ✅ | ✅ | ❌ | - | ✅ |
| Firefox (v 84.0) | ✅ | ✅ | ❔ | ❌ | ✅ |
By varying the number of bits that corresponds to the number of redirects to subpaths, this attack can be scaled almost arbitrarily.
It can distinguish 2^N unique users, where N is the number of redirects on the client side.
The time taken for the read and write operation increases as the number of distinguishable clients does.
In order to keep the number of redirects as minimal as possible, N can have a dynamic length.
More about this here.
I am a twenty year old student from 🇩🇪 Germany. I like to work in software design and development and have an interest in the IT security domain.
This repository, including the setup of a demonstration portal, was created within two days as part of a private research project on the topic of "Tracking on the Web".
Liked the project? Just give it a star ⭐ and spread the world!