Information Leaks via Safari's Intelligent Tracking Prevention
Artur Janc, Krzysztof Kotowicz, Lukas Weichselbaum, Roberto Clapis
IInformation Leaks via Safari’s
Intelligent Tracking Prevention artur janc, krzysztof kotowicz, lukas weichselbaum, roberto clapis
ABSTRACT
Intelligent Tracking Prevention (ITP) is a privacy mechanism implemented by Apple’s Safari browser,released in October 2017[1]. ITP aims to reduce the cross-site tracking of web users by limiting thecapabilities of cookies and other website data[2].As part of a routine security review, the Information Security Engineering team at Google has identifiedmultiple security and privacy issues in Safari’s ITP design. These issues have a number of unexpectedconsequences, including the disclosure of the user’s web browsing habits, allowing persistent cross-sitetracking, and enabling cross-site information leaks[3] (including cross-site search[4]).This report is a modestly expanded version of our original vulnerability submission to Apple (WebKitbug
The aim of Safari’s Intelligent Tracking Prevention mechanism is to protect users from trackingacross the web by preventing websites commonly loaded in a third-party context from receivinginformation which would allow them to identify the user. This functionality has two core elements: ● Establishing an on-device list of prevalent domains based on the user’s web traffic. ● Applying privacy restrictions to cross-site requests to domains designated as prevalent.When Safari notices a website sending a cross-site resource request, it increases an internalcounter for the domain from which the resource is loaded (referred to as an
ITP strike throughoutthis report). Once a given domain has accumulated enough ITP strikes, it is categorized by Safarias a prevalent domain. Details of the classification logic evolve and are beyond the scope of thisdocument; in our testing, being used in a third-party context by other domains was consistentlysufficient for Safari to designate a domain as prevalent.The prevalent domain list (referred to as the ITP list below) is stored at the granularity ofregistrable domains; specifically, Safari stores the eTLD+1, accounting for the Public Suffix List[7].When Safari makes a cross-site request to a prevalent domain, it applies privacy restrictionsto remove information that would allow that domain to infer the user’s identity and cross-link itwith third-party requests from other websites. It does so by removing cookies and truncating the
Referer header to include only the referring document’s origin instead of its full URL.The ITP list is append-only, but it is cleared whenever the user clears their Safari browsinghistory; the entire list is wiped even if the user resets history for a short time period. PrivateBrowsing Mode does not reuse the ITP list from the main browsing profile.
As a result of customizing the ITP list based on each user’s individual browsing patterns, Safari hasintroduced global state into the browser, which can be modified and detected by every document.Any site can issue cross-site requests, increasing the number of ITP strikes for an arbitrarydomain and forcing it to be added to the user’s ITP list. By checking for the side effects of ITPtriggering for a given cross-site HTTP request, a website can determine whether its domain ispresent on the user’s ITP list; it can repeat this process and reveal ITP state for any domain.ecause the ITP list implicitly stores information about the websites visited by the user, leakingits state reveals sensitive private information about the user’s browsing habits. Attacks
A key component of several of the described attacks is the ability to determine if an arbitrarydomain is on the user’s ITP list; we discuss this before moving on to the details of the attacks.It is of course trivial to detect the ITP status of any domains under the attacker’s control: theattacker can directly issue cross-site requests from another domain and inspect them for the effectsof applying ITP restrictions. For example, the attacker can check if the
Referer header has beentruncated, or if a cookie previously set in a first-party context was present in the request; ITP’sdesign can do little to prevent this capability. / attack -->