Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #14560

Closed (moved)
Open
Opened Jan 30, 2015 by Trac@tracbot

Tor Browser: Font probing vulnerability using dynamically generated iframes

Hello,

I'm a computer science student at TU Darmstadt, Germany, and as a part of my Master Thesis about the development of browser fingerprinting countermeasures I examined the anti-fingerprinting capabilities of Tor Browser. As a result of this examination I found a flaw in the protection against font probing that can be used to probe for an inexhaustible amount of fonts. I developed a small JavaScript application that can test for more than 600 fonts in less than a second (see attached). This vulnerability poses a risk to a user's privacy, as it can potentially be used to track users over the course of several browser sessions and among various websites.

Description:

Tor browser limits the total number of fonts that can be used in a document. By default, a document can use 10 fonts. So if a fingerprinter tries to probe for more than 10 fonts, he only gets reported that these fonts are missing. However, this design has a flaw, as it didn't consider that iframes also have their own document body. Therefore, in order to circumvent this limitation, a fingerprinting script might dynamically generate an iframe for each package of 10 fonts, probe for their existence, until all fonts have been probed for.

**Note: **The maximum number of possible fonts can be changed by the user. The fingerprinting script could easily probe for this threshold, as I found out that an already loaded font can't be loaded again, once this limit is reached.

The script:

I implemented a small script based on this observation. It creates iframes and probes for 10 fonts, using HTML 5 canvas element and the function measureText() provided by JavaScript. I assume that this approach also works with the classical implementation using CSS + JS, but I leave the experiments to some one else. For the script and a screenshot see the appended files.

Trac:
Username: Peter_Baumann_TUD

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#14560