An Evaluation of the Google Chrome Extension Security Architecture

Nicholas Carlini, Adrienne Porter Felt, and David Wagner University of California, Berkeley [email protected], [email protected], [email protected]

Abstract developers need to build extensions that are robust to attacks originating from malicious websites and the net- Vulnerabilities in browser extensions put users at risk by work. Extensions can read and manipulate content from providing a way for website and network attackers to websites, make unfettered network requests, and access gain access to users’ private data and credentials. Exten- browser userdata like bookmarks and geolocation. In the sions can also introduce vulnerabilities into the websites hands of a web or network attacker, these privileges can that they modify. In 2009, Google Chrome introduced be abused to collect users’ private information and au- a new extension platform with several features intended thentication credentials. to prevent and mitigate extension vulnerabilities: strong Google Chrome employs three mechanisms to prevent isolation between websites and extensions, privilege sep- and mitigate extension vulnerabilities: aration within an extension, and an extension permission system. We performed a security review of 100 Chrome extensions and found 70 vulnerabilities across 40 exten- • Privilege separation. Chrome extensions adhere to sions. Given these vulnerabilities, we evaluate how well a privilege-separated architecture [23]. Extensions each of the security mechanisms defends against exten- are built from two types of components, which are sion vulnerabilities. We find that the mechanisms mostly isolated from each other: content scripts and core succeed at preventing direct web attacks on extensions, extensions. Content scripts interact with websites but new security mechanisms are needed to protect users and execute with no privileges. Core extensions do from network attacks on extensions, website metadata at- not directly interact with websites and execute with tacks on extensions, and vulnerabilities that extensions the extension’s full privileges. add to websites. We propose and evaluate additional de- • Isolated worlds. Content scripts can read and mod- fenses, and we conclude that banning HTTP scripts and ify website content, but content scripts and websites inline scripts would prevent 47 of the 50 most severe vul- have separate program heaps so that websites can- nerabilities with only modest impact on developers. not access content scripts’ functions or variables. • Permissions. Each extension comes packaged with a list of permissions, which govern access to the 1 Introduction browser APIs and web domains. If an extension has a core extension vulnerability, the attacker will only Browser extensions can introduce serious security vul- gain access to the permissions that the vulnerable nerabilities into users’ browsers or the websites that ex- extension already has. tensions interact with [20, 32]. In 2009, Google Chrome introduced a new extension platform with several secu- In this work, we provide an empirical analysis of rity mechanisms intended to prevent and mitigate ex- these security mechanisms, which together comprise a tension vulnerabilities. Safari and Mozilla Firefox have state-of-the-art least privilege system. We analyze 100 since adopted some of these mechanisms for their own Chrome extensions, including the 50 most popular ex- extension platforms. In this paper, we evaluate the se- tensions, to determine whether Chrome’s security mech- curity of the widely-deployed Google Chrome extension anisms successfully prevent or mitigate extension vulner- platform with the goal of understanding the practical suc- abilities. We find that 40 extensions contain at least one cesses and failures of its security mechanisms. type of vulnerability. Twenty-seven extensions contain Most extensions are written by well-meaning devel- core extension vulnerabilities, which give an attacker full opers who are not security experts. These non-expert control over the extension. Based on this set of vulnerabilities, we evaluate the 2 Extension Security Background effectiveness of each of the three security mechanisms. Our primary findings are: 2.1 Threat Model • The isolated worlds mechanism is highly successful In this paper, we focus on non-malicious extensions that at preventing content script vulnerabilities. are vulnerable to external attacks. Most extensions are • The success of the isolated worlds mechanism ren- written by well-meaning developers who are not secu- ders privilege separation unnecessary. However, rity experts. We do not consider malicious extensions; privilege separation would protect 62% of exten- preventing malicious extensions requires completely dif- sions if isolated worlds were to fail. In the remain- ferent tactics, such as warnings, user education, security ing 38% of extensions, developers either intention- scans of the market, and feedback and rating systems. ally or accidentally negate the benefits of privilege Benign-but-buggy extensions face two types of attacks: separation. This highlights that forcing developers to divide their software into components does not automatically achieve security on its own. • Network attackers. People who use insecure net- • Permissions significantly reduce the severity of half works (e.g., public WiFi hotspots) may encounter of the core extension vulnerabilities, which demon- network attackers [26, 21]. A network attacker’s strates that permissions are effective at mitigating goal is to obtain personal information or credentials vulnerabilities in practice. Additionally, dangerous from a target user. To achieve this goal, a network permissions do not correlate with vulnerabilities: attacker will read and alter HTTP traffic to mount developers who write vulnerable extensions use per- man-in-the-middle attacks. (Assuming that TLS missions the same way as other developers. works as intended, a network attacker cannot compromise HTTPS traffic.) Consequently, data and Although these mechanisms reduce the rate and scope scripts loaded over HTTP may be compromised. of several classes of attacks, a large number of high- privilege vulnerabilities remain. If an extension adds an HTTP script – a JavaScript We propose and evaluate four additional defenses. Our file loaded over HTTP – to itself, a network attacker extension review demonstrates that many developers do can run arbitrary JavaScript within the extension’s not follow security best practices if they are optional, so context. If an extension adds an HTTP script to we propose four mandatory bans on unsafe coding prac- an HTTPS website, then the website will no longer tices. We quantify the security benefits and functional- benefit from the confidentiality, integrity, and au- ity costs of these restrictions on extension behavior. Our thentication guarantees of HTTPS. Similarly, insert- evaluation shows that banning inline scripts and HTTP ing HTTP data into an HTTPS website or extension scripts would prevent 67% of the overall vulnerabilities can lead to vulnerabilities if the untrusted data is al- and 94% of the most dangerous vulnerabilities at a rela- lowed to execute as code. tively low cost for most extensions. In concurrent work, Google Chrome implemented Content Security Policy • Web attackers. Users may visit websites that host (CSP) for extensions to optionally restrict their own be- malicious content (e.g., advertisements or user com- havior. Motivated in part by our study [5], future versions ments). A website can launch a cross-site script- of Chrome will use CSP to enforce some of the manda- ing attack on an extension if the extension treats the tory bans that we proposed and evaluated. website’s data or functions as trusted. The goal of a web attacker is to gain access to browser userdata Contributions. We contribute the following: (e.g., history) or violate website isolation (e.g., read • We establish the rate at which extensions contain another site’s password). different types of vulnerabilities, which should direct future extension security research efforts. Extensions are primarily written in JavaScript and • We perform the first large-scale study of the ef- HTML, and JavaScript provides several methods for con- fectiveness of privilege separation when developers verting strings to code, such as eval and setTimeout. who are not security experts are required to use it. If used improperly, these methods can introduce code • Although it has been assumed that permissions mit- injection vulnerabilities that compromise the extension. igate vulnerabilities [12, 14, 10], we are the first to Data can also execute if it is written to a page as evaluate the extent to which this is true in practice. HTML instead of as text, e.g., through the use of • We propose and evaluate new defenses. This study document.write or document.body.innerHTML. Ex- partially motivated Chrome’s adoption of a new tension developers need to be careful to avoid passing mandatory security mechanism. unsanitized, untrusted data to these execution sinks. Network attacker Network attacker (if website is HTTP) (if connection is HTTP)

Extension Website Content Script Core Extension Servers [attacker]

Browser API

Figure 1: The architecture of a Google Chrome extension.

2.2 Chrome Extension Security Model • Isolated worlds. The isolated worlds mechanism is intended to protect content scripts from web attack- Many Firefox extensions have publicly suffered from ers. A content script can read or modify a website’s vulnerabilities [20, 32]. To prevent this, the Google DOM, but the content script and website have sepa- Chrome extension platform was designed to protect users rate JavaScript heaps with their own DOM objects. from vulnerabilities in benign-but-buggy extensions [4]. Consequently, content scripts and websites never It features three primary security mechanisms: exchange pointers. This should make it more dif- • Privilege separation. Every Chrome extension is ficult for websites to tamper with content scripts.1 composed of two types of components: zero or more content scripts and zero or one core extension. • Permissions. By default, extensions cannot use Content scripts read and modify websites as needed. parts of the browser API that impact users’ privacy The core extension implements features that do not or security. In order to gain access to these APIs, a directly involve websites, including browser UI el- developer must specify the desired permissions in a ements, long-running background jobs, an options file that is packaged with the extension. For exam- page, etc. Content scripts and core extensions run in ple, an extension must request the bookmarks per- separate processes, and they communicate by send- mission to read or alter the user’s bookmarks. Per- ing structured clones over an authenticated channel. missions also restrict extensions’ use of cross-origin Each website receives its own separate, isolated in- XMLHttpRequests; an extension needs to specify stance of a given content script. Core extensions can the domains that it wants to interact with. Only the access Chrome’s extension API, but content scripts core extension can use permissions. Content scripts cannot invoke browser APIs or make cross-origin cannot. Figure 1 illustrates the relationship between 2 components in a Chrome extension. XHRs. A content script has only two privileges: it can access the website it is running on, and send The purpose of this architecture is to shield the priv- messages to its core extension. ileged part of an extension (i.e., the core extension) from attackers. Content scripts are at the highest Permissions are intended to mitigate core extension 3 risk of attack because they directly interact with vulnerabilities. An extension is limited to the per- websites, so they are low-privilege. The sheltered missions that its developer requested, so an attacker core extension is higher-privilege. As such, an at- cannot request new permissions for a compromised tack that only compromises a content script does extension. Consequently, the severity of a vulnera- not pose a significant threat to the user unless the bility in an extension is limited to the API calls and attack can be extended across the message-passing domains that the permissions allow. channel to the higher-privilege core extension. 1.4% of extensions also include binary plugins in addition to content scripts and core extensions [12]. 1Although isolated worlds separates websites from content scripts, Binary plugins are native executables and are not it not a form of privilege separation; privilege separation refers to tech- protected by any of these security mechanisms. We niques that isolate parts of the same application from each other. do not discuss the security of binary plugins in this 2In newer versions of Chrome, content scripts can make cross- paper because they are infrequently used and must origin XHRs. However, this was not permitted at the time of our study. 3Extension permissions are shown to users during installation, so undergo a manual security review before they can they may also have a role in helping users avoid malicious extensions; be posted in the Chrome Web Store. however, we focus on benign-but-buggy extensions in this work. Google Chrome was the first browser to implement DOM of a page. After observing an extension, we privilege separation, isolated worlds, and permissions for inserted malicious data into its network traffic (in- an extension system. These security mechanisms were cluding the websites it interacts with) to test poten- intended to make Google Chrome extensions safer than tial vulnerabilities. Mozilla Firefox extensions or Internet Explorer browser helper objects [4]. Subsequently, Safari adopted an iden- 2. Source code analysis. We examined extensions’ tical extension platform, and Mozilla Firefox’s new Add- source code to determine whether data from an on SDK (Jetpack) privilege-separates extension mod- untrusted source could flow to an execution sink. ules. All of our study findings are directly applicable to After manually reviewing the source code, we Safari’s extension platform, and the privilege separation used grep to search for any additional sources or evaluation likely translates to Firefox’s Add-on SDK. sinks that we might have missed. For sources, Contemporaneously with our extension review, the we looked for static and dynamic script inser- Google Chrome extension team began to implement tion, XMLHttpRequests, cookies, bookmarks, and a fourth security mechanism: Content Security Policy reading websites’ DOMs. For sinks, we looked (CSP) for extensions. CSP is a client-side HTML pol- for uses of eval, setTimeout, document.write, icy system that allows website developers to restrict what innerHTML, etc. We then manually traced the call types of scripts can run on a page [29]. It is intended to graph to find additional vulnerabilities. prevent cross-site scripting attacks by blocking the exe- 3. Holistic testing. We matched extensions’ source cution of scripts that have been inserted into pages. By code to behaviors we identified during black-box default, CSP disables inline scripts: JavaScript will not testing. With our combined knowledge of an ex- run if it is in a link, between