You may not be aware that the security standard HTTP Strict Transport Security (HSTS) can be misused as a supercookie to secretly track users of any web browser online without their knowledge even if they browse via private browsing feature.
Apple added mitigations to its open-source browser infrastructure WebKit that underpins its Safari web browser to prevent HSTS abuse after discovering that theoretical attacks were recently deployed in the wild against Safari users.
HSTS—HTTP Strict Transport Security—is an excellent feature that enables websites to automatically redirects user’s web traffic to secure page connections over HTTPS in situations where the user accidentally opens an insecure URL and then remembers to route that user to the secure connection always.
HSTS does not allow websites to store any information on user’s web browser except the redirect information about turning it on/off for future use. By using this information, an attacker who needs to track web users can create a so-called supercookie that can then be read by cross-site tracking servers to mark users across websites.
Let’s See How HSTS-Based Tracking Operates:
To understand the working of the HSTS supercookie tracking let’s take an 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.
- Every time the user visits the same website, it automatically 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).
- Combining the above value reveals the user’s unique binary value to the server, helping websites/advertisers to mark users across sites.
Apple has now added two mitigations to its Safari’s WebKit engine which 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 hackers 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).
The developers at Safari WebKit engine says that WebKit 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 averts the trackers from setting HSTS across large numbers of different bits; but they must individually visit each domain representing an active bit in the tracking identifier. The content providers and advertisers may judge that the latency introduced by a single redirect through one origin to set many bits is undetectable by the user while redirects to 32 or more domains to set the bits of the identifier would be noticed by 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.
Apple hasn’t mentioned any individual, organization, or any advertising firm that was using HSTS supercookie tracking to target Safari users.