使用favicon追踪用户,即使在隐身模式下。
Browser fingerprinting via favicon

原始链接: https://github.com/jonasstrehle/supercookie

## 超级Cookie:一种新型追踪方法 “超级Cookie”是一种利用浏览器书签图标缓存——“F-Cache”——来唯一识别网站访问者的追踪技术。与传统Cookie不同,这种方法具有惊人的持久性,可以存活于隐身模式、缓存清除、浏览器重启、VPN和广告拦截器中。 该技术通过观察浏览器*请求*哪些书签图标以及哪些已经存储在其F-Cache中来工作。通过分析跨多个页面加载的这种模式,可以为每个浏览器分配一个唯一的标识符。这是因为书签图标被本地缓存并持久保存,以加快页面加载速度。 该项目通过一个在线演示和提供的源代码来展示这种漏洞,旨在突出潜在的隐蔽追踪可能性。虽然在主流浏览器(Chrome、Firefox、Safari、Edge)和平台上都有效,但攻击的可扩展性取决于使用的书签图标重定向数量。 目前的缓解措施包括手动清除F-Cache(提供了Chrome、Safari和Edge的说明),因为浏览器缺乏针对此漏洞的内置保护。该技术的创建者是一位学生研究员,他开发此项目是为了探索网络追踪的可能性。

使用收藏夹图标跟踪用户,即使在隐身模式下 (github.com/jonasstrehle) 10 分,由 vxvrs 51 分钟前发布 | 隐藏 | 过去 | 收藏 | 3 条评论 gitmagic 6 分钟前 | 下一个 [–] 演示应该做什么?我只是陷入了一个无尽的重定向循环,计数器从 1 到 18 然后重新开始。我使用的是 iOS 上的 Safari。回复 breppp 9 分钟前 | 上一个 [–] 我确定这已经存在一段时间了,或者 Safari 长期以来一直存在 UI 错误。我经常在特定网站上看到错误的收藏夹图标,例如 Reddit 上显示 Ars Technica 的收藏夹图标。回复 robotnikman 7 分钟前 | 父级 [–] 我有时也会在 Firefox 中遇到同样的错误。回复 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系方式 搜索:
相关文章

原文

supercookie

Documentation

Website Status License

Fingerprint index N Redirects

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 operating system, using a VPN or installing AdBlockers. 🍿 Live demo.

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.

📕 Full documentation

requirements: Docker daemon

  1. Clone repository
git clone https://github.com/jonasstrehle/supercookie
  1. 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
  1. Run container
cd supercookie/server
docker-compose up

-> Webserver will be running at https://yourdomain.com

requirements: Node.js

  1. Clone repository
git clone https://github.com/jonasstrehle/supercookie
  1. Update .env file in supercookie/server/.env
HOST_MAIN=localhost:10080
PORT_MAIN=10080

HOST_DEMO=localhost:10081
PORT_DEMO=10081
  1. Run service
cd supercookie/server
node --experimental-json-modules main.js

-> Webserver will be running at http://localhost:10080

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.

Supercookie Header

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

Info
Chrome (v 111.0) ? -
Safari (v 14.0) - - - -
Edge (v 87.0) -
Firefox (v 86.0) Fingerprint different in incognito mode
Brave (v 1.19.92) -

Browser

Windows

MacOS

Linux

iOS

Android

Info
Brave (v 1.14.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.

The most straightforward solution is to disable the favicon cache completely. As long as the browser vendors do not provide a feature against this vulnerability it's probably the best way to clear the F-cache.

  • ChromeMacOS

    • Delete ~/Library/Application Support/Google/Chrome/Default/Favicons
    • Delete ~/Library/Application Support/Google/Chrome/Default/Favicons-journal
  • ChromeWindows

    • Delete C:\Users\username\AppData\Local\Google\Chrome\User Data\Default
  • SafariMacOS

    • Delete content of ~/Library/Safari/Favicon Cache
  • EdgeMacOS

    • Delete ~/Library/Application Support/Microsoft Edge/Default/Favicon
    • Delete ~/Library/Application Support/Microsoft Edge/Default/Favicons-journal

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".

ko-fi

Liked the project? Just give it a star ⭐ and spread the world!

联系我们 contact @ memedata.com