Cross-Origin JavaScript Capability Leaks: Detection, Exploitation, and Defense Adam Barth Joel Weinberger Dawn Song UC Berkeley UC Berkeley UC Berkeley [email protected] [email protected] [email protected] Abstract a script attempts to access the cookie database, the DOM checks whether the script’s security origin We identify a class of Web browser implementation has sufficient privileges to access the cookies. cross-origin JavaScript capability leaks vulnerabilities, , • Object-Capabilities. The JavaScript engine en- which occur when the browser leaks a JavaScript pointer forces the same-origin policy using an object- from one security origin to another. We devise an algo- capability discipline that prevents one Web site rithm for detecting these vulnerabilities by monitoring from obtaining JavaScript pointers to sensitive ob- the “points-to” relation of the JavaScript heap. Our algo- jects that belong to a foreign security origin. With- rithm finds a number of new vulnerabilities in the open- out JavaScript pointers to sensitive objects in for- source WebKit browser engine used by Safari. We pro- eign security origins, malicious scripts are unable pose an approach to mitigate this class of vulnerabilities to interfere with those objects. by adding access control checks to browser JavaScript engines. These access control checks are backwards- Most modern Web browsers, including Internet Ex- compatible because they do not alter semantics of the plorer, Firefox, Safari, Google Chrome, and Opera, use Web platform. Through an application of the inline this design. However, the design’s mismatch in en- cache, we implement these checks with an overhead of forcement paradigms leads to vulnerabilities whenever 1–2% on industry-standard benchmarks. the browser leaks a JavaScript pointer from one secu- rity origin to another. Once a malicious script gets a 1 Introduction JavaScript pointer to an honest JavaScript object, the at- In this paper, we identify a class of Web browser im- tacker can leverage the object-capability security model plementation vulnerabilities, which we refer to as cross- of the JavaScript engine to escalate its DOM privileges. origin JavaScript capabilities leaks, and develop sys- With escalated DOM privileges, the attacker can com- tematic techniques for detecting, exploiting, and defend- pletely compromise the honest security origin by inject- ing against these vulnerabilities. An attacker who ex- ing a malicious script into the honest security origin. ploits a cross-origin JavaScript capability leak can in- To study this class of vulnerabilities, we devise an al- ject a malicious script into an honest Web site’s secu- gorithm for detecting individual cross-origin JavaScript rity origin. These attacks are more severe than cross- capability leaks. Using this algorithm, we uncover new site scripting (XSS) attacks because they affect all Web instances of cross-origin JavaScript capability leaks in sites, including those free of XSS vulnerabilities. Once the WebKit browser engine used by Safari. We then il- an attacker can run script in an arbitrary security origin, lustrate how an attack can abuse these leaked JavaScript the attacker can, for example, issue transactions on the pointers by constructing proof-of-concept exploits. We user’s bank account, regardless of any SSL encryption, propose defending against cross-origin JavaScript capa- cross-site scripting filter, or Web application firewall. bility leaks by harmonizing the security models used by We observe that these cross-origin JavaScript capa- the DOM and the JavaScript engine. bility leaks are caused by an architectural flaw shared • Leak Detection. We design an algorithm for au- by most modern Web browsers: the Document Object tomatically detecting cross-origin JavaScript ca- Model (DOM) and the JavaScript engine enforce the pability leaks by monitoring the “points-to” rela- same-origin policy using two different security models. tion among JavaScript objects in the heap. From The DOM uses an access control model, whereas the this relation, we define the security origin of each JavaScript engine uses object-capabilities. JavaScript object by tracing its “prototype chain.” • Access Control. The DOM enforces the same- We then search the graph for edges that connect ob- origin policy using a reference monitor that pre- jects in one security origin with objects in another vents one Web site from accessing resources allo- security origin. These suspicious edges likely rep- cated to another Web site. For example, whenever resent cross-origin JavaScript capability leaks. • Vulnerabilities and Exploitation. We implement leaks as a class of vulnerabilities. Section 3 presents our our leak detection algorithm and find two new high- algorithm for detecting cross-origin JavaScript capabil- severity cross-origin JavaScript capability leaks in ity leaks. Section 4 details the individual vulnerabili- WebKit. Although these vulnerabilities are imple- ties we uncover with our algorithm and outlines tech- mentation errors in WebKit, the presence of the niques for exploiting these vulnerabilities. Section 5 bugs illustrates the fragility of the general architec- proposes defending against cross-origin JavaScript ca- ture. (Other browsers have historically had similar pability leaks by adding access control checks to the vulnerabilities [17, 18, 19].) We detail these vulner- JavaScript engine. Section 6 relates our work to the lit- abilities and construct proof-of-concept exploits to erature. Section 7 concludes. demonstrate how an attacker can leverage a leaked JavaScript pointer to inject a malicious script into 2 JavaScript Capability Leaks an honest security origin. In this section, we describe our interpretation of • Defense. We propose that browser vendors proac- JavaScript pointers as object-capabilities and identify tively defend against cross-origin JavaScript capa- cross-origin JavaScript capability leaks as a class of im- bility leaks by implementing access control checks plementation vulnerabilities in browsers. We then sketch throughout the JavaScript engine instead of reac- how these vulnerabilities are exploited and the conse- tively plugging each leak. Adding access control quences of a successful exploit. checks to the JavaScript engine addresses the root cause of these vulnerabilities (the mismatch be- 2.1 Object-Capabilities tween the security models used by the DOM and In modern Web browsers, the JavaScript engine en- by the JavaScript engine) and provides defense-in- forces the browser’s same-origin policy using an object- depth in the sense that both an object-capability capability discipline: a script can obtain pointers only and an access control failure are required to create to JavaScript objects created by documents in its se- an exploitable vulnerability. This defense is per- curity origin. A script can obtain JavaScript point- fectly backwards-compatible because these access ers to JavaScript objects either by accessing prop- checks do not alter the semantics of the Web plat- erties of JavaScript object to which the script al- form. Our implementation of these access control ready has a JavaScript pointer or by conjuring cer- checks in WebKit incurs an overhead of only 1–2% tain built-in objects such as the global object and on industry-standard benchmarks. Object.prototype [14]. As in other object- Contributions. We make the following contributions: capability systems, the ability to influence an object is tied to the ability to designate the object. In browsers, • We identify a class of Web browser implementa- a script can manipulate a JavaScript object only if the tion vulnerabilities: cross-origin JavaScript capa- script has a pointer to the object. Without a pointer to bility leaks. These vulnerabilities arise when the an object in a foreign security origin, a malicious script browser leaks a JavaScript pointer from one secu- cannot influence honest JavaScript objects and cannot rity origin to another security origin. interfere with honest security origins. • We introduce an algorithm for detecting cross- One exception to this object-capability discipline is origin JavaScript capability leaks by monitoring the the JavaScript global object. According to the HTML 5 “points-to” relation of the JavaScript heap. Our al- specification [10], the global object (also known as the gorithm uses a graph-based definition of the secu- window object) is visible to foreign security origins. rity origin of a JavaScript object. There are a number of APIs for obtaining pointers to • We reveal cross-origin JavaScript capability leaks global objects from foreign security origins. For exam- and demonstrate techniques for exploiting these ple, the contentWindow property of an <iframe> vulnerabilities. These exploits rely on the mis- element is the global object of the document contained match between the DOM’s access control security in the frame. Unlike most JavaScript objects, the global model and the JavaScript engine’s object-capability object is also a DOM object (called window) and is security model. equipped with a reference monitor that prevents scripts • We propose that browsers defend against cross- in foreign security origins from getting or setting arbi- origin JavaScript capability leaks by implement- trary properties of the object. This reference monitor ing access control checks in the JavaScript engine. does not forbid all accesses because some are desirable. This defense is perfectly backwards-compatible For example, the postMessage