This article is more than 1 year old
Apple moves on HSTS abuse in Safari
WebKit updated to kill 'supercookies'
Apple has moved to block an abuse vector in the WebKit framework that underpins its Safari browser and allows HSTS to be abused to act as a 'supercookie' for user tracking.
HSTS – HTTP Strict Transport Security – allows a Web site to declare to browsers that it's only accessible via HTTPS. If a user tries to hit the HTTP-only version of a site, they'll be redirected to the HTTPS service.
The bug in that feature was that a site could use the redirect information to act as a tracking supercookie, because the HSTS standard stipulates that Web browsers should remember a redirection for future use.
Here's how it's described in RFC 6797:
UAs [User Agents – El Reg] need to retain persistent data about web sites that signal strict security policy enablement, for time spans declared by the web sites. Additionally, UAs need to cache the "freshest" strict security policy information, in order to allow web sites to update the information.
The RFC recognises the potential for HSTS tracking, and the abuse possibilities were demonstrated in 2015.
At that time, we reported research by Sam Greenhalgh, who wrote that an HSTS “pin” is set for each HTTPS-redirected site you use, it's unique to user and site, and it's readable from your browser settings by any site. Those pins could be recovered in the future, and the user doesn't get a chance to clear them.
“In short, an attacker could set HSTS on or off for an arbitrary number of subdomains for a domain they own”, Helme wrote, and this post at the Webkit blog, by Brent Fulgham, expands with what Apple has observed.
… an attacker could set HSTS on or off for an arbitrary number of subdomains for a domain they own
“An attacker seeking to track site visitors can take advantage of the user’s HSTS cache to store one bit of information on that user’s device. For example, 'load this domain with HTTPS' could represent a 1, while no entry in the HSTS cache would represent a 0,” the post said.
“By registering some large number of domains (e.g., 32 or more), and forcing resource loads from a controlled subset of those domains, they can create a large enough vector of bits to uniquely represent each site visitor.”
Having observed privacy attacks in the wild, Fulgham wrote, it was necessary to find a fix without undermining HSTS.
In WebKit, he wrote, Apple has decided to mitigate “both sides of the attack” by limiting HSTS state to the TLD; and address how HSTS state is recorded.
“Mitigation One”, addresses the cookie-setting problem: attackers iterating long add-ons to the TLD (one example from the post is below):
https://bit00.example.com https://bit01.example.com https://bit02.example.com ...etc... https://bit64.example.com
The network stack only sets the HSTS state to be set for either the loaded hostname, or the “TLD plus one”, 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.”
In “Mitigation Two”, “Ignore HSTS State for Subresource Requests to Blocked Domains”, WebKit blocks things like invisible tracking pixels from forcing an HSTS redirect. As a result, the supercookie becomes a string of zeroes. ®