Apple has added new protections to the WebKit framework to prevent possible abuse of the HTTP Strict Transport Security (HSTS) security standard to track users.
HSTS offers a mechanism through which web sites declare themselves accessible only via secure connections and direct browsers to where that secure version resides. Basically, when a user attempts to connect to the insecure version of a website, HSTS forces the browser to go to the HTTPS version of the site instead.
“This is a great feature that prevents a simple error from placing users in a dangerous state, such as performing financial transactions over an unauthenticated connection,” WebKit software engineer Brent Fulgham points out.
However, because HSTS tells web browsers to remember when redirected to a secure location and to automatically go there in the future, a “super cookie” can be created, and it can be read by cross-site trackers, Fulgham says.
An attacker could leverage the user’s HSTS cache to store one bit of information on the device. Through registering a large number of domains and forcing the loading of resources from controlled subset of domains, the attacker “can create a large enough vector of bits to uniquely represent each site visitor.”
The issue is described in the HSTS specs: “it is possible for those who control one or more HSTS Hosts to encode information into domain names they control and cause such UAs to cache this information as a matter of course in the process of noting the HSTS Host. This information can be retrieved by other hosts through cleverly constructed and loaded web resources, causing the UA to send queries to (variations of) the encoded domain names.”
According to Fulgham, mitigating such tracking attacks isn’t easy, as it requires balancing security and privacy goals. However, because the privacy risks of HSTS have been presented only as a theoretical tracking vector but evidence of actual malicious abuse of the protocol hasn’t been provided yet, browsers would honour all HSTS instructions provided by sites.
The engineer also reveals that Apple recently became aware that this theoretical attack has started being deployed against Safari users. This prompted the tech giant to create a solution to both protect secure web traffic and mitigate tracking.
Because the HSTS exploit requires creating an initial tracking identifier and then reading it, Apple proposes mitigations for both sides of the attack.
On the one hand, Apple revised the network stack to only permit HSTS state to be set for the loaded hostname or the Top Level Domain + 1. Thus, trackers can no longer efficiently set HSTS across large numbers of different bits, but need to individually visit
each domain that has an active bit in the tracking identifier. WebKit also caps the number of redirects that can be chained together, thus limiting the number of bits that can be set.
On the other hand, Apple also modified WebKit to ignore HSTS upgrade requests (and use the original URL) when dynamic HSTS results in an insecure third-party subresource loaded from a domain with blocked cookies being upgraded to an authenticated connection.
“Telemetry gathered during internal regression testing, our public seeds, and the final public software release indicates that the two mitigations described above successfully prevented the creation and reading of HSTS super cookies while not regressing the security goals of first party content. We believe them to be consistent with best practices, and to maintain the important security protections provided by HSTS,” Fulgham concludes.
Related: Google Expands HSTS Preload List
Related: Cookies Render HTTPS Sessions Vulnerable to Data Leaks