Latex Gloves: Protecting Browser Extensions from Probing and Revelation Attacks

Abstract

Browser extensions enable rich experience for the users of today's web. Being deployed with elevated privileges, extensions are given the power to overrule web pages. As a result, web pages often seek to detect the installed extensions, sometimes for benign adoption of their behavior but sometimes as part of privacy-violating user fingerprinting. Researchers have studied a class of attacks that allow detecting extensions by probing for Web Accessible Resources (WARs) via URLs that include public extension IDs. Realizing privacy risks associated with WARs, Firefox has recently moved to randomize a browser extension's ID, prompting the Chrome team to plan for following the same path. However, rather than mitigating the issue, the randomized IDs can in fact exacerbate the extension detection problem, enabling attackers to use a randomized ID as a reliable fingerprint of a user. We study a class of extension revelation attacks, where extensions reveal themselves by injecting their code on web pages. We demonstrate how a combination of revelation and probing can uniquely identify 90% out of all extensions injecting content, in spite of a randomization scheme. We perform a series of large-scale studies to estimate possible implications of both classes of attacks. As a countermeasure, we propose a browser-based mechanism that enables control over which extensions are loaded on which web pages and present a proof of concept implementation which blocks both classes of attacks. Probing attack: Previous works [55], [53] have focused on non-behavioral detection, based on a browser extension's listed WARs. The WARs are public resources which can be fetched from the context of a web page using a predefined URL, consisting of a public extension ID (or Universally Unique Identifier (UUID)) and the path to that resource. With the predefined URL to fetch a WAR from an extension, a web page can mount a probing attack, designed to detect an extension by probing for WARs, since a response with the probed WAR indicates the corresponding extension is installed. This attack can be seen in Figure 1a where 1 denotes the requests made by the attacker to probe for an installed browser extension. If the browser extension is in the browser context, the attacker will get a response consisting of the requested WAR (denoted by 2). This attack can be magnified by probing for a set of browser extensions' resources, thereby enumerating

Carnus: Exploring the Privacy Threats of Browser Extension Fingerprinting

“…As demonstrated by our experimental evaluation, the countermeasure proposed by Trickel et al [55] is ineffective against the vast majority of our behavioral fingerprints. Two other studies [46], [50] recently proposed whitelist-based countermeasures for mediating access between extensions and web pages, and a similar approach has been announced by Chrome [6]. These mechanisms can potentially reduce the fingerprint surface exposed to certain domains, but the ones that users whitelist will still be able to run the attacks we demonstrated.…”

“…As mentioned previously, prior studies have demonstrated the feasibility of browser extension enumeration and fingerprintability. These studies focused their efforts on identifying extensions that expose specific resources (i.e., WAR-based enumeration) either directly [24], [47] or with clever implicit approaches [44], [46]. In the following subsections we provide technical details and outline the fingerprint generation and extension detection process for our four techniques.…”

“…Next, in Table II we compare to prior work and find that our system has created the largest set of detectable extensions to date. Most of these studies [24], [44], [46], [47] focused on detecting extensions through exposed WARs (either directly or through some indirect/side channel) -we statically analyzed over 102K extensions to create the most complete collection of Chrome extension WAR fingerprints. More importantly, we create the first collection of automatically generated behavioral extension fingerprints, which enable our novel analysis and evaluation of their deployment in a realistic setting.…”

“…Due to the potential risk, browsers do not provide any mechanism that would allow a visited webpage to directly obtain the list of installed browser extensions. In practice, however, webpages can indirectly infer which extensions are installed [24], [44], [46], [47]. Once the list of installed extensions is obtained, it can be used as part of a user's device fingerprint and coupled with other browser [18], [33], [40] or system level [13] information, which can lead to the tracking of users across the web [8], [19].…”

After you, please: browser extensions order attacks and countermeasures

“…Additionally, our scenario can handle situations where, two browser extensions developed by the same person or company but placed for instance at the beginning and at the end of the execution queue will actually access to different information and thus, collaborate to perform attacks like browser hijacking [19,13], or fingerprinting [15,10] attacks.…”