CONSCRIPT: Specifying and Enforcing Fine-Grained Security Policies for JavaScript in the Browser Leo A. Meyerovich Benjamin Livshits University of California, Berkeley Microsoft Research [email protected] [email protected] Abstract—Much of the power of modern Web comes from the instance, an included library might perform a prototype ability of a Web page to combine content and JavaScript code hijacking attack [1], drastically redefining the behavior of from disparate servers on the same page. While the ability the remainder of the JavaScript code on the page. to create such mash-ups is attractive for both the user and the developer because of extra functionality, code inclusion CONSCRIPT, a browser-based aspect system for security effectively opens the hosting site up for attacks and poor proposed in this paper, focuses on empowering the hosting programming practices within every JavaScript library or API page to carefully constrain the code it executes. For ex- it chooses to use. In other words, expressiveness comes at the ample, the hosting page may restrict the use of eval to price of losing control. To regain the control, it is therefore JSON only, restrict cross-frame communication or cross- valuable to provide means for the hosting page to restrict the behavior of the code that the page may include. domain requests, allow only white-listed script to be loaded, This paper presents CONSCRIPT1, a client-side advice im- limit popup window construction, limit JavaScript access to plementation for security, built on top of Internet Explorer 8. cookies, disallow dynamic IFRAME creations, etc. These CONSCRIPT allows the hosting page to express fine-grained constraints take the form of fine-grained policies expressed application-specific security policies that are enforced at run- as JavaScript aspects that the hosting page can use to change time. In addition to presenting 17 widely-ranging security and reliability policies that CONSCRIPT enables, we also show how the behavior of subsequent code. In CONSCRIPT, this kind policies can be generated automatically through static analysis of behavior augmentation is done via the script include tag of server-side code or runtime analysis of client-side code. We to provide a policy as follows: also present a type system that helps ensure correctness of CONSCRIPT policies. <SCRIPT SRC="script.js" POLICY="function () {...}"> CONSCRIPT To show the practicality of in a range of settings, With CONSCRIPT, the first general browser-based policy we compare the overhead of CONSCRIPT enforcement and conclude that it is significantly lower than that of other systems enforcement mechanism for JavaScript to our knowledge, proposed in the literature, both on micro-benchmarks as well at a relatively low cost of several hundred lines of code as large, widely-used applications such as MSN, GMail, Google added to the JavaScript engine, we gain vast expressive Maps, and Live Desktop. power. This paper presents 17 widely-ranging security and Keywords-JavaScript; Web and client-side programming; reliability policies that CONSCRIPT enables. To collect these aspects; browsers; language security; security policies policies, we studied bugs and anti-patterns in both “raw” JavaScript as well as popular JavaScript libraries such as I. INTRODUCTION jQuery. We also found bugs in and have rewritten many of the policies previously published in the literature [2, Much of the power of modern Web comes from the ability 3] in CONSCRIPT. We discovered that in many cases a of a Web page to combine HTML and JavaScript code from few lines of policy code can be used instead of a new, disparate servers on the same page. For instance, a mash- specialized HTML tag. Our experience demonstrates that up such as a Yelp! page describing a restaurant may use CONSCRIPT provides a general enforcement mechanism for APIs from Google Maps to show the restaurant’s location, a wide range of application-level security policies. We also jQuery libraries to provide visual effects, and Yelp APIs show how classes of CONSCRIPT policies can be generated to obtain the actual review and rating information. While automatically, with static analysis of server-side code or the ability to create such client-side mash-ups within the runtime analysis of client-side code, removing the burden same page is attractive for both the user and the developer on the developer for specifying the right policy by hand. because of the extra functionality this provides, because Finally, we propose a type system that makes it considerably of including untrusted JavaScript code, the hosting page easier to avoid common errors in policies. effectively opens itself up to attacks and poor programming practices from every JavaScript library or API it uses. For We built CONSCRIPT by modifying the JavaScript inter- preter in the Internet Explorer 8 Web browser. This paper 1The name CONSCRIPT has been chosen to reflect our desire to restrict describes our implementation, correctness considerations malicious script. one has to take into account when writing CONSCRIPT policies, as well as the results of our evaluation on a results. Finally, Sections VIII and IX describe related work range of benchmarks, both small programs and large-scale and conclude. applications such as MSN, GMail, and Live Desktop. II. OVERVIEW A. Contributions This section presents an overview of the use of advice to This paper makes the following contributions. enforce security and reliability properties in a browser. Security aspects in the browser. We present a case for the use of aspects for enforcement of rich application-specific A. Browser Enforcement of Application Policies policies by the browser. Unlike previous fragile wrapper Many Web security policies are being proposed for both or rewriting aspect systems for the Web and dynamic lan- browsers and Web applications [4–6]. Similarly, correspond- guages, we advocate deep aspects that are directly supported ing enforcement mechanisms at the browser and script levels by the JavaScript and browser runtimes. Modifying the are also being advocated. These proposals highlight the JavaScript engine allows us to easily enforce properties that diverse nature of Web security policies and suggest that the are difficult or impossible to fully enforce otherwise. security concerns of a Web application are often orthogonal Correctness checking for aspects. CONSCRIPT proposes from those of the browser. static and runtime validation strategies that ensure that Currently, when determining how to enforce security aspects cannot be subverted through common attack vectors policies of a Web application by using browser-level or script found in the literature. rewriting and wrapping approaches, there are large trade- Policies. We present 17 wide-ranging security and reliability offs in granularity, performance, and correctness [7–9]. We policies. We show how to concisely express these policies propose to expose browser mechanisms and to make them in CONSCRIPT, often with only several lines of JavaScript accessible through an advice system. Doing so lowers perfor- code. These policies fall intro the broad categories of con- mance and code complexity barriers for current cross-cutting trolling script introduction, imposing communication restric- security policies (and those that have been too difficult or tions, limiting dangerous DOM interactions, and restricting onerous to implement). Furthermore, enabling applications API use. To our knowledge, this is the most comprehensive to deploy their own policies decreases the reliance upon catalog of application-level security policies for JavaScript browser upgrades to mitigate security threats. available to date. B. Motivating Policy Example in CONSCRIPT Automatic policy generation. To further ease the policy specification burden on developers, we advocate automatic We start our description of CONSCRIPT advice by show- policy generation. We demonstrate two examples of di- ing a motivating example of how it may be used in practice. rectly enforcing CONSCRIPT policies automatically gener- One feature of the JavaScript language that is often consid- ated through static or runtime analysis. ered undesirable for security is the eval construct. At the same time, because this construct is often used to de-serialize We implemented the techniques described in Evaluation. JSON strings, it is still commonly used. A na¨ıve approach this paper in the context of Internet Explorer 8. We assess to prevent unrestricted use of eval involves redefining eval the performance overhead of our client-side enforcement as follows: strategy on the overall program execution of real programs such as Google Maps and Live Desktop, as well as a set window.eval = function() / ...safe version... / ; of JavaScript micro-benchmarks previously used by other { ∗ ∗ } researchers. We conclude that CONSCRIPT results in runtime However, references to the native eval functions are dif- enforcement overheads that hover around 1% for most large ficult to hide fully. This is because window.eval and benchmarks, which is considerably smaller than both time window.parent.eval, for instance, are both aliases for and space overheads incurred by implementations previously the same function in the JavaScript interpreter. Are there proposed in the literature. other access paths specified by Web standards, or, perhaps, provided by some non-standard browser feature for a par- B. Paper Organization ticular release? Another issue is that some native JavaScript The rest of the paper