Apple has now added mitigations to its open-source browser infrastructure WebKit that underpins its Safari web browser to prevent HSTS abuse after discovering that theoretical attacks demonstrated in 2015 were recently deployed in the wild against Safari users.
HSTS—HTTP Strict Transport Security—is a great feature that allows websites to automatically redirects user's web traffic to secure page connections over HTTPS if the user accidentally opens an insecure URL and then remembers to route that user to the secure connection always.
Since HSTS does not allow websites to store any information/value on users web browser except remembering the redirect information about turning it on/off for future use, using this information, someone interested in tracking web users can create a so-called supercookie that can then be read by cross-site tracking servers to mark users across websites.
Here's How HSTS-Based Tracking Works:
To understand how HSTS supercookie tracking works, here's a simple example:
- To track each user, sites assign a unique random number to each visitor, for example, 909090, where 32 character binary conversion for 909090 is 00000000000011011101111100100010.
- To set this binary number for a specific user, the site sets HSTS policy for its 32 subdomains (tr01.example.com, tr02.example.com......and tr32.example.com) accordingly, where if HSTS for a subdomain is enabled then the value is 1 and if not then the value is 0.
- Now each time the user visits the same website, it silently opens invisible pixels from 32 of its subdomains in the background that represent the bits in the binary number, signalling the server which subdomains are opened via HTTPS (1) and which via HTTP (zero).
- Voila! Combining the above value reveals the user's unique binary value to the server, helping websites/advertisers to mark users across sites.
However, Apple has now added two mitigations to its Safari's WebKit engine that addresses both sides of the attack: where tracking identifiers are created, and the subsequent use of invisible pixels to track users.
Mitigation One addresses the super cookie-setting problem, where attackers use long URLs that encode the digits in subdomains of the main domain name and the practice of setting HSTS across a wide range of sub-domains at once.
Safari will now limit the HSTS state to either the loaded Hostname, or the Top Level Domain plus one (TLD+1), and "WebKit also caps the number of redirects that can be chained together, which places an upper bound on the number of bits that can be set, even if the latency was judged to be acceptable."
"This prevents trackers from efficiently setting HSTS across large numbers of different bits; instead, they must individually visit each domain representing an active bit in the tracking identifier," says Brent Fulgham, a developer who works on Safari WebKit engine.
"While content providers and advertisers may judge that the latency introduced by a single redirect through one origin to set many bits is imperceptible to a user, requiring redirects to 32 or more domains to set the bits of the identifier would be perceptible to the user and thus unacceptable to them and content providers."In Mitigation Two, Safari ignores HSTS State for Subresource Requests to Blocked Domains, where WebKit blocks things like invisible tracking pixels from forcing an HSTS redirect, causing HSTS supercookies to become a bit string of only zeroes.
However, Apple does not name any individual, organisation, or any advertising firm that was using HSTS supercookie tracking to target Safari users.
