Client-Side Diversification for Defending Against

Everyone is Different: Client-side Diversification for Defending Against Extension Fingerprinting Erik Trickel, Arizona State University; Oleksii Starov, Stony Brook University; Alexandros Kapravelos, North Carolina State University; Nick Nikiforakis, Stony Brook University; Adam Doupé, Arizona State University https://www.usenix.org/conference/usenixsecurity19/presentation/trickel

This paper is included in the Proceedings of the 28th USENIX Security Symposium. August 14–16, 2019 • Santa Clara, CA, USA 978-1-939133-06-9

Open access to the Proceedings of the 28th USENIX Security Symposium is sponsored by USENIX. Everyone is Different: Client-side Diversiﬁcation for Defending Against Extension Fingerprinting

Erik Trickel?, Oleksii Starov†, Alexandros Kapravelos‡, Nick Nikiforakis†, and Adam Doupé? ?Arizona State University †Stony Brook University {etrickel, doupe}@asu.edu {ostarov, nick}@cs.stonybrook.edu ‡North Carolina State University [email protected]

Abstract by users, as they see fit, by installing browser extensions. Namely, Google Chrome and Mozilla Firefox, the browsers Browser fingerprinting refers to the extraction of attributes with the largest market share, offer dedicated browser exten- from a user’s browser which can be combined into a near- sion stores that house tens of thousands of extensions. In turn, unique fingerprint. These fingerprints can be used to re- these extensions advertise a wide range of additional features, identify users without requiring the use of cookies or other such as enabling the browser to store passwords with online stateful identifiers. Browser extensions enhance the client- password managers, blocking ads, and saving articles for later side browser experience; however, prior work has shown that reading. their website modifications are fingerprintable and can be From a security perspective, the ability to load third-party used to infer sensitive information about users. code into the browser comes at a cost, even though extensions In this paper we present CloakX, the first client-side anti- rely on web technologies such as HTML, JavaScript, and fingerprinting countermeasure that works without requiring CSS. Browsers afford extensions significantly more privileges browser modification or requiring extension developers to than they do to a webpage. For example, the same origin modify their code. CloakX uses client-side diversification to policy restricts webpages from accessing content, such as a prevent extension detection using anchorprints (fingerprints cookie, that does not originate from the same domain. For a comprised of artifacts directly accessible to any webpage) webpage to bypass this restriction, it must implement cross- and to reduce the accuracy of extension detection using struc- origin resource sharing, whereas extensions may not only tureprints (fingerprints built from an extension’s behavior). access resources of any domain but may also alter the content. Despite the complexity of browser extensions, CloakX au- Historically, malicious extensions abuse these privileges to tomatically incorporates client-side diversification into the perform advertising fraud and to steal private and financial extensions and maintains equivalent functionality through the user data [22, 28, 44, 47]. use of static and dynamic program analysis. We evaluate the efficacy of CloakX on 18,937 extensions using large-scale Next to security issues, using browser extensions can also automated analysis and in-depth manual testing. We con- lead to the loss of privacy. Given that users choose the ex- ducted experiments to test the functionality equivalence, the tensions to install, it is possible to make inferences about a detectability, and the performance of CloakX-enabled ex- user’s thoughts and beliefs based solely on the extensions she tensions. Beyond extension detection, we demonstrate that keeps. For example, the detection of a coupon-finding ex- client-side modification of extensions is a viable method for tension [1] reveals information about the user’s income-level. the late-stage customization of browser extensions. Additionally, an extension that hides articles about certain political figures [20, 21] reveals the user’s political leanings. Lastly, the use of browser extensions may provide a means 1 Introduction for websites to persistently identify a user over the course of distinct browser sessions. As the web expands and continues being the platform of Although browser vendors do not offer any programmatic choice for delivering applications to users, the browser be- methods for a webpage’s JavaScript to detect the extensions comes a core component of a user’s interactions with the web. currently installed in a user’s browser, researchers recently Modern browsers advertise a wide range of features, from discovered side-channel techniques for fingerprinting many cloud-syncing and notifications to password management and extensions. Sjösten et al. were the first to demonstrate a new peer-to-peer video and audio communications. An important method for detecting browser extensions that exploited the feature of modern browsers is their ability to be extended public nature of web-accessible resources (WARs) [38]. A

USENIX Association 28th USENIX Security Symposium 1679 WAR is any resource (e.g., JavaScript or image) within an obfuscates the extension’s structureprint. As a result, an ex- extension that the extension identifies as externally accessi- tension cloaked by CloakX is undetectable by a webpage ble. As a result, a webpage can determine whether a visitor using anchorprints and is obfuscated from a webpage using uses an extension by requesting one of the exposed WARs. structureprints; however, from the user’s point of view, the Sjösten et al. showed that more than 50% of the top 1,000 extension operates the same. browser extensions use WARs, which any webpage might use In summary, we make the following contributions: to detect extensions. Later, Starov and Nikiforakis demon- • We present the design of a novel system that automati- strated another technique for fingerprinting extensions that cally identifies and randomizes browser extension finger- uses an extension’s modifications to the document-object- prints to defend against existing extension fingerprinting model (DOM) to detect their presence [42]. The authors de- techniques without requiring any browser changes or veloped XHOUND, a system that automatically discovers the any involvement from the extension’s developer. DOM side-effects of extensions. Through their experiments, • We describe the implementation of our design into a they showed that more than 10% of the top 50K extensions prototype, CloakX, that uses a combination of: (1) static were fingerprintable. rewriting of extension JavaScript code and (2) a dynamic One approach to reducing fingerprintable extensions is DOM proxy, Droxy, that intercepts and rewrites exten- through education and developer training. However, his- sion requests on-the-fly. torically, developers — and web developers in particular — • We use a combination of high-fidelity testing (exten- ignore even well-known security concerns. Even after nearly sive manual testing) and low-fidelity testing (broad auto- 20 years, the most common website vulnerabilities are still mated testing) on the extensions rewritten by CloakX to SQL injection vulnerabilities [43]. Therefore, it is unlikely quantify the breakage caused by our system, demonstrat- that asking extension developers to make their extensions less ing that client-side modification of extensions introduces fingerprintable will have the desired effect on the ecosystem. minimal defects. To empower users to protect their own privacy, in this pa- • We also evaluate the detectability of cloaked extensions per we propose CloakX, a client-side countermeasure against and show that some cloaked extensions are undetectable extension detection using fingerprints. Instead of trying to while others are more difficult to detect. remove the fingerprintable attributes of extensions, our approach is to automatically alter, randomize, and add to these 2 Background attributes without requiring web browser modifications or any involvement from the extension’s developer. Through In this section, we provide insights into the complexity of these modifications, CloakX diversifies the extension’s an- modern browser extension frameworks that must be taken into chorprints, which are fingerprints consisting of items that account when designing a client-side countermeasure against can be accessed directly from a webpage, and structureprints, extension fingerprinting. We start by describing the architec- which are fingerprints that embody the structural changes ture of browser extensions, focusing on the details that pertain an extension makes to a webpage (for more details refer to their fingerprintability. Next, we discuss fingerprinting and to Section 2.2). On the surface, client-side diversification detecting extensions using anchorprints (fingerprints that are of the fingerprintable attributes seems straightforward; how- comprised of items directly accessible from a tracking web- ever, the dynamic nature of JavaScript and the complexity page’s JavaScript) and structureprints (fingerprints built from of the browser extension’s architecture necessitated a com- the extension’s behavior). Last, we finish this section by plex approach that relies on both static and dynamic program presenting the threat model that CloakX can defend against. analysis. CloakX uses static and dynamic analysis techniques to 2.1 Browser Extensions Explained automatically diversify the extension’s fingerprint without modifying the browser, without requiring any changes by the While modern web browsers provide an ever-increasing range extension’s author, and without altering the extension’s func- of functionality to users and webpages, an off-the-shelf tionality. To diversify the extension’s anchorprint, CloakX browser cannot possibly provide a sufficiently large set of fea- automatically renames WARs, IDs, and class names and cor- tures to satisfy every user’s browsing needs. To improve the rects any references to them in the extension’s code, which user’s browsing experience, browsers enable users to enhance severs the link between the published extension and the cur- their functionality through extensions. Users add extensions rently installed version. In addition to static changes, the to their browsers to change the browser’s look, to add helpful diversification is also performed by our dynamic DOM proxy toolbars, to block ads, and to enhance popular webpages [5]. (Droxy), which intercepts DOM modifications from the ex- Although extensions utilize web technologies such as tension’s code and makes the changes on-the-fly. To diversify HTML, CSS, and JavaScript, they also have access to pow- the extension’s structureprint, Droxy also injects random tags, erful extension-only APIs that enable them to, among oth- attributes, and custom attributes into each webpage, which ers, access and modify cross-origin content and a browser’s

1680 28th USENIX Security Symposium USENIX Association Figure 1: Extension architecture. A high-level overview of Chrome’s extension architecture with the static content of the extension on the left side and the multiple execution environments on the right. Background pages can 1) inject content scripts dynamically using the executeScript() method in Chrome’s extension API and 2) send and receive messages from the content scripts. client-side storage. However, before an extension can ac- matically inject a content script, an extension must call exe- cess broader privileges or interact with a webpage, it must cuteScript() from a background page (see 1 in Figure1). request this access from the browser. As Figure1 depicts, the To modify a webpage, a content script uses the webpage’s modern extension architecture implements a layered security DOM [10]. DOM APIs provide a systematic way for interact- approach within the browser that creates multiple execution ing with a webpage. In this paper, we call the content script’s environments with varying levels of persistence and privileges interaction with the DOM APIs DOM requests. for each extension and webpage. Notice in Figure1 that the background page, content scripts, The left-hand side of Figure1 depicts the static parts of an and webpage each run their own JavaScript execution envi- extension, including items such as the manifest, JavaScript, ronment. The separate execution environments prevent the HTML, and image files. For the browser to parse and in- JavaScript variables and functions from directly interacting. stall an extension, it must have a manifest file which defines Google Chrome’s documentation states that content scripts the extension’s properties. Similar to the manifest shown “live in an isolated world, allowing a content script to make in Figure1, extensions commonly rely on three properties, changes to its JavaScript environment without conflicting with which describe background pages, content scripts, and web the page or additional content scripts”[3] (emphasis added). accessible resources [5]. This statement, however, is misleading because we experi- mentally discovered that content scripts loaded from the same When the background property is included in the exten- extension share variables and can call functions from other sion’s manifest, the browser automatically constructs a hidden content scripts. Thus, an extension’s content scripts share a background page for the extension. The background page single execution environment; however, they do not share an contains HTML, a DOM, and a separate JavaScript execu- environment with the background page, webpage, or other tion environment (labeled as “Background Page” in Figure1). extensions (depicted in Figure1). The JavaScript executed in the background page often con- Using DOM requests, a content script has significant contains the main logic of the extension, maintains long-term trol over the rendered webpage. Content scripts can inject state, and operates independently from the life-cycle of the HTML into the webpage (using DOM element properties such webpages [28]. as innerHTML or DOM methods such as appendChild()). Content scripts bridge the gap between the background We call this injected HTML droplets (the extension drops page and the current webpage. An extension uses content them onto the webpage). Among other elements, droplets scripts to modify the current webpage and communicate with may contain