Flexible Access Control for JavaScript Gregor Richards1 Christian Hammer2 Francesco Zappa Nardelli3 Suresh Jagannathan1 Jan Vitek1 1 Purdue University 2 Saarland University 3 INRIA Abstract agencies. Other attacks leverage the extension facilities of Providing security guarantees for systems built out of un- some popular web sites. Facebook, for example, encourages trusted components requires the ability to define and enforce third party extensions to be delivered as JavaScript plugins. access control policies over untrusted code. In Web 2.0 ap- Taxonomies of these attacks are emerging [19]. Attacks such plications, JavaScript code from different origins is often as cross site scripting, cookie stealing, location hijacking, clickjacking, history sniffing and behavior tracking are be- combined on a single page, leading to well-known vulner- 2 abilities. We present a security infrastructure which allows ing catalogued, and the field is rich and varied. Barth et al. users and content providers to specify access control policies even proposed a name for this threat model: the Gadget At- over subsets of a JavaScript program by leveraging the con- tacker [2,5]. cept of delimited histories with revocation. We implement What makes the JavaScript platform challenging is that our proposal in WebKit and evaluate it with three policies on applications that run in a single client-side browser are com- 50 widely used websites with no changes to their JavaScript posed on the fly, their source code is assembled from dif- code and report performance overheads and violations. ferent sources and run in the same environment with little isolation. Moreover JavaScript is very dynamic; text can be 1. Introduction turned into code at any time and very few properties can be statically guaranteed [30]. Our study of real-world Java- Many popular Web applications mix content from different Script behavior demonstrated that this dynamism is widely sources, such as articles coming from a newspaper, a search used [31]. Web browsers offer two lines of defense for end- bar provided by a search engine, advertisements served by users: The first is a sandbox that protects the operating sys- a commercial partner, and included third-party libraries to tem from JavaScript code. The second is known as the same enrich the user experience. The behavior of such a web site origin policy (SOP); it segregates components into trust do- depends on all of its parts working, especially so if it is fi- mains based on their origin (a combination of host name, nanced by ads. Yet, not all parts are equally trusted. Typi- port and protocol) and enforces access control restriction on cally, the main content provider is held to a higher standard elements of the web page with a different origin. However, than the embedded third-party elements. A number of well the SOP is not uniformly applied to all resources (e.g. im- publicized attacks have shown that ads and third-party com- ages may come from different origins, potentially leaking in- ponents can introduce vulnerabilities in the overall applica- formation in their URLs), and it is too coarse-grained. While tion. Readers of the New York Times online version were the SOP prevents scripts in one frame from accessing con- subject to a scareware attack originating from code provided tent in another, many web sites choose not to use frames as 1 by a previously trustworthy ad agency. Similarly, German this form of isolation is highly restrictive, and far from fool- newspapers were attacked by malware from a legitimate ad- proof [5]. Thus much third-party code is simply included in vertisement service which delegated some ads to second-tier the body of the web page [26]. 1 www.nytimes.com/2009/09/15/technology/internet/15adco.html, The majority of attempts to strengthen the security of www.h-online.com/security/features/Tracking-down-malware-949079. Web 2.0 applications rely on isolating trusted from un- html. trusted code and limiting the dynamism of JavaScript, either through static analysis techniques which reject programs that do not meet certain static criteria or by defining a subset Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed of the language that is easier to verify [12, 13, 23–25]. These for profit or commercial advantage and that copies bear this notice and the full citation approaches have been adopted by the industry as exemplified on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, by Facebook JavaScript, Yahoo’s AdSafe, or Google Caja. to post on servers or to redistribute to lists, requires prior specific permission and/or a However, these techniques can be circumvented [34] and can fee. Request permissions from [email protected]. OOPSLA ’13, October 29–31, 2013, Indianapolis, IN, USA. Copyright c 2013 ACM 978-1-4503-2374-1/13/10. $15.00. 2 www.webappsec.org/projects/threat, http://dx.doi.org/10.1145/2509136.2509542 www.owasp.org/index.php/Category:Attack. miss attacks due to peculiarities and leniencies of different enforceable security policies are a superset of [33] as re- browsers’ JavaScript parsers, and they are so restrictive that vocation allows access decisions based on future events. many valid legacy programs would be rejected. • Support of existing JavaScript browser security mecha- This paper proposes a novel security infrastructure for nisms: All JavaScript objects are owned by a principal. dealing with the Gadget Attacker threat model. We extend Ownership is integrated with the browser’s same origin JavaScript objects with dynamic ownership annotations and principle for backwards compatibility with Web 2.0 ap- break up a web site’s computation at ownership changes, that plications. Code owned by an untrusted principal is exe- is to say when code belonging to a different owner is exe- cuted in a controlled environment, but the code has full cuted, into delimited histories. Subcomputations performed access to the containing page. This ensures compatibility on behalf of untrusted code are executed under a special with existing code. regime in which most operations are recorded into histo- ries. Then, at the next ownership change, or at other well • Browser integration: Our system was implemented in the defined points, these histories are made available to user- WebKit library. We instrument all means to create scripts configurable security policies which can, if the history vio- in the browser at runtime, so if untrusted code creates lates some safety rule, issue a revocation request. Revocation another script we add its security principal to the new undoes all the computational effects of the history, reverting script as well. Additionally, we treat the eval function as the state of the heap to what it was before the computation. untrusted and always monitor it. Delimiting histories is crucial for our technique to scale to • Flexible policies: Our security policies allow enforce- real web sites. While JavaScript pages can generate millions ment of semantic properties based on the notion of secu- of events, histories are typically short, and fit well within the rity principals attached to JavaScript objects, rather than computation model underlying Web 2.0 applications: once mere syntactic properties like method or variable names the history of actions of an untrusted code fragment is vali- that previous approaches generally rely on. Policies can dated, the history can be discarded. Histories allow policies be combined, allowing for both provider-specified secu- to reason about the impact of an operation within a scope by rity and user-defined security. giving policies a view on the outcome of a sequence of com- • Empirical Evaluation: We validated our approach on 50 putational steps. Consider storing a secret into an object’s real web sites and two representative policies. The results field. This could be safe if the modification was subsequently suggest that our model is a good fit for securing web ad overwritten and replaced by the field’s original value. Tradi- content and third-party extensions, with less than 10% of tional access control policies would reject the first write, but sites’ major functionality broken. Our policies have suc- policies in our framework can postpone the decision and ob- cessfully prevented dangerous operations performed by serve if this is indeed a leak. While policies of interest could third-party code. The observed performance overheads stretch all the way to dynamic information flow tracking, we were between 11% and 106% in the interpreter. focus on access control in this paper. Targeting Web applications means that we must deal with Our work builds on and combines ideas from the literature. the idiosyncrasies of modern web browsers and propose a History-based access control [1] extends the stack inspec- security model that could be deployed without disrupting tion security model of Java to include a history of methods the ecosystem. Our main design constraint was thus back- called. Inline reference monitors [33, 37] dynamically en- wards compatibility with the web. For this reason our design force a security policy by monitoring system execution with carefully avoids extending the syntax of JavaScript and does security automata. We build on their insight and record a not require changes to code that is already well-behaved. wider selection of operations. The design of our policy lan- Our proposal can be integrated into a web browser with no guage is informed by Polymer [6]. While the notion of revo- modifications of the implementation of existing web sites. cation is inspired by research on transactional memory [16], We leverage the existing SOP policy and use it as a build- we avoid the transactional memory terminology because de- ing block in our infrastructure.