Protecting Users by Confining Javascript with COWL Deian Stefan and Edward Z

Home , JavaScript

Protecting Users by Confining JavaScript with COWL Deian Stefan and Edward Z. Yang, Stanford University; Petr Marchenko, Google; Alejandro Russo, Chalmers University of Technology; Dave Herman, Mozilla; Brad Karp, University College London; David Mazières, Stanford University https://www.usenix.org/conference/osdi14/technical-sessions/presentation/stefan

This paper is included in the Proceedings of the 11th USENIX Symposium on Operating Systems Design and Implementation. October 6–8, 2014 • Broomfield, CO 978-1-931971-16-4

Open access to the Proceedings of the 11th USENIX Symposium on Operating Systems Design and Implementation is sponsored by USENIX. Protecting Users by Conﬁning JavaScript with COWL † Deian Stefan∗ Edward Z. Yang Petr Marchenko Alejandro Russo Dave Herman Stanford Stanford Google Chalmers Mozilla Brad Karp David Mazieres` UCL Stanford

ABSTRACT contributors to the tangle of JavaScript comprising an Modern web applications are conglomerations of application may not have the user’s best interest at heart. JavaScript written by multiple authors: application devel- The wealth of sensitive data processed in today’s web opers routinely incorporate code from third-party libraries, applications (e.g., email, bank statements, health records, and mashup applications synthesize data and code hosted passwords, etc.) is an attractive target. Miscreants may at different sites. In current browsers, a web application’s stealthily craft malicious JavaScript that, when incorpo- developer and user must trust third-party code in libraries rated into an application by an unwitting developer, vio- not to leak the user’s sensitive information from within lates the user’s privacy by leaking sensitive information. applications. Even worse, in the status quo, the only way Two goals for web applications emerge from the prior to implement some mashups is for the user to give her lo- discussion: flexibility for the application developer (i.e., gin credentials for one site to the operator of another site. enabling the building of applications with rich functional- Fundamentally, today’s browser security model trades pri- ity, composable from potentially disparate pieces hosted vacy for flexibility because it lacks a sufficient mechanism by different sites); and privacy for the user (i.e., to en- for confining untrusted code. We present COWL, a robust sure that the user’s sensitive data cannot be leaked from JavaScript confinement system for modern web browsers. applications to unauthorized parties). These two goals COWL introduces label-based mandatory access control are hardly new: Wang et al. articulated similar ones, and to browsing contexts in a way that is fully backward- proposed new browser primitives to improve isolation compatible with legacy web content. We use a series of within mashups, including discretionary access control case-study applications to motivate COWL’s design and (DAC) for inter-frame communication [41]. Indeed, to- demonstrate how COWL allows both the inclusion of un- day’s browsers incorporate similar mechanisms in the trusted scripts in applications and the building of mashups guises of HTML5’s iframe sandbox and postMessage that combine sensitive information from multiple mutu- API [47]. And the Same-Origin Policy (SOP, reviewed in ally distrusting origins, all while protecting users’ privacy. Section 2.1) prevents JavaScript hosted by one principal Measurements of two COWL implementations, one in from reading content hosted by another. Firefox and one in Chromium, demonstrate a virtually Unfortunately, in the status-quo web browser security imperceptible increase in page-load latency. architecture, one must often sacrifice privacy to achieve flexibility, and vice-versa. The central reason that flex- 1 INTRODUCTION ibility and privacy are at odds in the status quo is that Web applications have proliferated because it is so easy the mechanisms today’s browsers rely on for providing for developers to reuse components of existing ones. Such privacy—the SOP, Content Security Policy (CSP) [42], reuse is ubiquitous. jQuery, a widely used JavaScript li- and Cross-Origin Resource Sharing (CORS) [45]—are brary, is included in and used by over 77% of the Quant- all forms of discretionary access control. DAC has the cast top-10,000 web sites, and 59% of the Quantcast top- brittle character of either denying or granting untrusted million web sites [3]. While component reuse in the ven- code (e.g., a library written by a third party) access to erable desktop software model typically involves libraries, data. In the former case, the untrusted JavaScript might the reusable components in web applications are not lim- need the sensitive data to implement the desired appli- ited to just JavaScript library code—they further include cation functionality—hence, denying access prioritizes network-accessible content and services. privacy over flexibility. In the latter, DAC exercises no The resulting model is one in which web developers control over what the untrusted code does with the sen- cobble together multiple JavaScript libraries, web-based sitive data—and thus prioritizes flexibility over privacy. content, and web-based services written and operated by DAC is an essential tool in the privacy arsenal, but does various parties (who in turn may integrate more of these re- not fit cases where one runs untrusted code on sensitive sources) and build the required application-specific func- input, which are the norm for web applications, given tionality atop them. Unfortunately, some of the many their multi-contributor nature.

∗Work partly conducted while at Mozilla. In practice, web developers turn their backs on privacy †Work partly conducted while at Stanford. in favor of ﬂexibility because the browser doesn’t offer

1 USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) 131 primitives that let them opt for both. For example, a de- a.com$ b.com$ veloper may want to include untrusted JavaScript from XHR$ XHR$ another origin in his application. All-or-nothing DAC leads the developer to include the untrusted library with JavaScript$ JavaScript$ a script tag, which effectively bypasses the SOP, in- postMessage$ terpolating untrusted code into the enclosing page and DOM$API$ DOM$API$ granting it unfettered access to the enclosing page’s ori- DOM$ DOM$ gin’s content.1 And when a developer of a mashup that a.com$ b.com$ integrates content from other origins finds that the SOP Figure 1: Simplified browser architecture. forbids his application from retrieving data from them, he designs his mashup to require that the user provide the our evaluation (Section 6) illustrates that COWL incurs mashup her login credentials for the sites at the two other minimal performance overhead over the respective origins [2]—the epitome of “functionality over privacy.” baseline browsers. In this paper, we present COWL (Confinement with Origin Web Labels), a mandatory access control (MAC) 2 BACKGROUND,EXAMPLES,&GOALS system that confines untrusted JavaScript in web browsers. A single top-level web page often incorporates multiple 2 COWL allows untrusted code to compute over sensitive scripts written by different authors. Ideally, the browser data and display results to the user, but prohibits the un- should protect the user’s sensitive data from unauthorized trusted code from exfiltrating sensitive data (e.g., by send- disclosure, yet afford page developers the greatest pos- ing it to an untrusted remote origin). It thus allows web sible flexibility to construct featureful applications that developers to opt for both flexibility and privacy. reuse functionality implemented in scripts provided by We consider four motivating example web applica- (potentially untrusted) third parties. To make concrete the tions—a password strength-checker, an application that diversity of potential trust relationships between scripts’ imports the (untrusted) jQuery library, an encrypted cloud- authors and the many ways page developers structure based document editor, and a third-party mashup, none amalgamations of scripts, we describe several example of which can be implemented in a way that preserves web applications, none of which can be implemented with the user’s privacy in the status-quo web security archi- strong privacy for the user in today’s web browsers. These tecture. These examples drive the design requirements examples illustrate key requirements for the design of a for COWL, particularly MAC with symmetric and hierar- flexible browser confinement mechanism. Before describ- chical confinement that supports delegation. Symmetric ing these examples, however, we offer a brief refresher on confinement allows mutually distrusting principals each status-quo browser privacy polices. to pass sensitive data to the other, and confine the other’s 2.1 Browser Privacy Policies use of the passed sensitive data. Hierarchical confinement Browsing contexts Figure 1 depicts the basic building allows any developer to confine code she does not trust, blocks of the current web security architecture. A brows- and confinement to be nested to arbitrary depths. And ing context (e.g., a page or frame) encapsulates pre- delegation allows a developer explicitly to confer the priv- sentable content and a JavaScript execution environment ileges of one execution context on a separate execution (heap and code) that interacts with content through the context. No prior browser security architecture offers this Document Object Model (DOM) [47]. Browsing contexts combination of properties. may be nested (e.g., by using iframes). They also may We demonstrate COWL’s applicability by implement- read and write persistent storage (e.g., cookies), issue ing secure versions of the four motivating applications network requests (either implicitly in page content that with it. Our contributions include: references a URL retrieved over the network, or explicitly We characterize the shared needs of four case-study in JavaScript, using the XMLHttpRequest (XHR) con- web applications (Section 2.2) for which today’s structor), and communicate with other contexts (IPC-style browser security architecture cannot provide privacy. via postMessage, or, in certain cases, by sharing DOM We describe the design of the COWL label-based objects). Some contexts such as Web Workers [44] run MAC system for web browsers (Section 3), which JavaScript but do not instantiate a DOM. We use the terms meets the requirements of the four case-study web context and compartment interchangeably to refer to both applications. browsing contexts and workers, except when the more We describe designs of the four case-study web appli- precise meaning is relevant. cations atop COWL (Section 4). Origins and the Same-Origin Policy Since different au- We describe implementations of COWL (Section 5) thors may contribute components within a page, today’s for the Firefox and Chromium open-source browsers; 2Throughout we use “web page” and “web application” interchange- 1Indeed, jQuery requires such access to the enclosing page’s content! ably, and “JavaScript code” and “script” interchangeably.

132 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) USENIX Association status quo browsers impose a security policy on interac- tion of which cross-origin communication is allowed and tions among components. Policies are expressed in terms which denied, but enforce no confinement on a receiving of origins. An origin is a source of authority encoded by compartment of differing origin. Thus, in the status-quo the protocol (e.g., https), domain name (e.g., fb.com), web security architecture, a privacy-conscious developer and port (e.g., 443) of a resource URL. For brevity, we should only send sensitive data to a compartment of dif- elide the protocol and port from URLs throughout. fering origin if she completely trusts that origin. The same-origin policy specifies that an origin’s re- 2.2 Motivating Examples sources should be readable only by content from the same origin [7, 38, 52]. Browsers ensure that code executing in Having reviewed the building blocks of security policies an a.com context can only inspect the DOM and cook- in status-quo web browsers, we now turn to examples of ies of another context if they share the same origin, i.e., web applications for which strong privacy is not achiev- a.com. Similarly, such code can only inspect the response able today. These examples illuminate key design require- to a network request (performed with XHR) if the remote ments for the COWL confinement system. host’s origin is a.com. Password Strength Checker Given users’ propensity The SOP does not, however, prevent code from disclos- for choosing poor (i.e., easily guessable) passwords, many ing data to foreign origins. For example, code executing web sites today incorporate functionality to check the in an a.com context can trivially disclose data to b.com strength of a password selected by a user and offer the by using XHR to perform a network request; the SOP user feedback (e.g., “too weak; choose another,” “strong,” prevents the code from inspecting responses to such cross- etc.). Suppose a developer at Facebook (origin fb.com) origin XHR requests, but does not impose any restrictions wishes to re-use password-checking functionality pro- on sending such requests. Similarly, code can exfiltrate vided in a JavaScript library by a third party, say, from data by encoding it in the path of a URL whose origin is origin sketchy.ru. If the developer at fb.com simply b.com, and setting the src property of an img element includes the third party’s code in a script tag referenc- to this URL. ing a resource at sketchy.ru, then the referenced script Content Security Policy (CSP) Modern browsers allow will have unfettered access to both the user’s password the developer to protect a user’s privacy by specifying a (provided by the Facebook page, which the library must CSP that limits the communication of a page—i.e., that see to do its job) and to write to the network via XHR. disallows certain communication ordinarily permitted by This simple state of affairs is emblematic of the ease with the SOP. Developers may set individual CSP directives to which na¨ıve web developers can introduce leaks of sensi- restrict the origins to which a context may issue requests tive data in applications. of specific types (for images or scripts, XHR destinations, A more skilled web developer could today host the etc.)[42]. However, CSP policies suffer from two limita- checker script on her own server and have that server tions. They are static: they cannot change during a page’s specify a CSP policy for the page. Unfortunately, a CSP lifetime (e.g., a page may not drop the privilege to com- policy that disallows scripts within the page from ini- municate with untrusted origins before reading potentially tiating XHRs to any other origins is too inflexible, in sensitive data). And they are inaccessible: JavaScript code that it precludes useful operations by the checker script, cannot inspect the CSP of its enclosing context or some e.g., retrieving an updated set of regular expressions de- other context, e.g., when determining whether to share scribing weak passwords from a remote server (essen- sensitive data with that other context. tially, “updating” the checker’s functionality). Doing so postMessage and Cross-Origin Resource Sharing requires communicating with a remote origin. Yet a CSP (CORS) As illustrated in Figure 1, the HTML5 policy that permits such communication, even with the postMessage API [43] enables cross-origin communi- top-level page’s same origin, is too permissive: a mali- cation in IPC-like fashion within the browser. To prevent cious script could potentially carry out a self-exfiltration unintended leaks [8], a sender always specifies the origin attack and write the password to a public part of the of the intended recipient; only a context with that origin trusted server [11, 50]. may read the message. This trade-off between flexibility and privacy, while in- CORS [45] goes a step further and allows controlled herent to CSP, need not be fundamental to the web model. cross-origin communication between a browsing context The key insight is that it is entirely safe and useful for an of one origin and a remote server with a different origin. untrusted script to communicate with remote origins be- Under CORS, a server may include a header on returned fore it reads sensitive data. We note, then, the requirement content that explicitly whitelists other origin(s) allowed of a confinement mechanism that allows code in a com- to read the response. partment to communicate with the network until it has Note that both postMessage’s target origin and CORS been exposed to sensitive data. MAC-based confinement are purely discretionary in nature: they allow static selec- meets this requirement.

USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) 133 1$ sketchy.ru$ Encrypted Document Editor Today’s web applications, 2$ such as in-browser document editors backed by cloud- 3$ 2$ [“password”][email protected]$ based storage (e.g., Google Docs), typically require 2$ the user to trust the app developer/cloud-based storage 2$ public$ public$ [email protected]$ provider (often the same principal under the SOP) with @.com$ the data in her documents. That is, the provider’s server

DOM$ observes the user’s data in cleartext. Suppose an organi- checker$ zation wished to use an in-browser document editor but 4$ 2$ [“weak”][email protected]$ did not want to reveal its users’ document data to the Figure 2: Third-party password checker architecture under editor provider’s server. How might the provider offer a COWL. privacy-preserving editor app that would satisfy the needs of such a privacy-conscious organization? One promising Figure 2 shows how such a design might look. In this approach might be for the “customer” privacy-sensitive and subsequent examples, rectangular frames denote com- organization to implement a trusted document encryption partments, arrows denote communication (either between service hosted at its own origin, distinct from that which a compartment and the network, or IPC-style between hosts the editor app. The editor app could allow the user compartments), and events during execution are num- to specify a JavaScript “plugin” library she trusts to per- bered sequentially in time. As we have proposed previ- form cryptography correctly. In this design, one origin ously [49], compartments may be labeled (Section 3.1) serves the JavaScript code for the editor app (say, gdocs with the origins to whose sensitive data they have been .com) and a different origin serves the JavaScript code for exposed. A compartment that has not yet observed sen- the cryptography library (say, eff.org). Note that these sitive data is denoted public; however, when it wishes two origins may be mutually distrusting. gdocs.com’s to incorporate sensitive data, the compartment raises its script must pass the document’s cleartext to a script from label (at the cost of being more restricted in where it can eff.org for encryption, but would like to confine the write). We illustrate the raising of a label with a “flash” execution of the encryption script so that it cannot exfil- connoting the sensitivity of data being integrated. A com- trate the document to any origin other than gdocs.com. partment’s privilege (Section 3.3), which specifies the Similarly, eff.org’s cryptography library may not trust origins for which a script executing in that compartment gdocs.com with the cleartext document—it would like is trusted, is indicated by a crown. Here, a top-level page to confine gdocs.com’s editor to prevent exfiltration of at fb.com encapsulates a password-checker script from a the cleartext document to gdocs.com (or to any other third-party origin in a new compartment. The label of the origin). This simple use case highlights the need for sym- new compartment is initially public. First, in step (1), metric confinement: when two mutually distrusting scripts the checker script is free to download updated regular ex- from different origins communicate, each must be able to pressions from an arbitrary remote origin. In step (2), the confine the other’s further use of data it provides. top-level page sends the user’s password to the checker Some of the most useful web ap- script’s worker using postMessage; the password is la- Third-Party Mashup plications are mashups; these applications integrate and beled fb.com to indicate that the data is sensitive to this origin (Section 3.2). In step (3) the checker raises its la- compute over data hosted by multiple origins. For exam- bel to reflect that the context is about to be exposed to ple, consider an application that reconciles a user’s Ama- zon purchases (the data for which are hosted by amazon sensitive data from fb.com and inspects the password. .com When the label is raised, COWL atomically denies the ) against a user’s bank statement (the data for which chase.com context further access to the network in step (3).3 How- are hosted by ). The user may well deem both ever, the checker script is free to compute the result, which these categories of data sensitive and will furthermore not want data from Amazon to be exposed to her bank it then returns via postMessage to the top-level page in or vice-versa, nor to any other remote party. Today, if step (4); the result carries the label fb.com to reflect that the sender may be sending data derived from sensitive one of the two providers implements the mashup, its application code must bypass the SOP to allow sharing of data owned by fb.com. Since the top-level page has the data across origin boundaries, e.g., by communicating be- fb.com privilege, it can simply read the data (without postMessage raising its label). tween iframes with or setting a permissive CORS policy. This approach forfeits privacy: one origin sends sensitive data to the other, after which the receiving origin may exfiltrate that sensitive data at will. Alterna- 3 For clarity, we use fb.com as the label on the data. This label still tively, a third-party developer may wish to implement allows the checker to send XHR requests to fb.com; to ensure that the checker cannot communicate with any origin, COWL provides fresh and offer this mashup application. Users of such a third- origins (see Section 3.3). party mashup give up their privacy, usually by simply

4 134 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) USENIX Association handing off credentials, as again today’s browser enforces browsers. To summarize, these applications would appear no policy that confines the sensitive data the mashup’s to be well served by a system that: code observes within the browser. To enable third-party Applies mandatory access control (MAC); mashups that do not sacrifice the user’s privacy, we note Is symmetric, i.e., it permits two principals to mutually again the need for an untrusted script to be able to issue distrust one another, and each prevent the other from requests to multiple remote origins (e.g., amazon.com exfiltrating its data; and chase.com), but to lose the privilege to commu- Is hierarchical, i.e., it permits principal A to confine nicate over the network once it has read the responses code from principal B that processes A’s data, while from those origins. Here, too, MAC-based confinement principal B can independently confine code from prin- addresses the shortcomings of DAC. cipal C that processes B’s data, etc. Untrusted Third-Party Library Web application devel- Supports delegation and dropping privilege, i.e., it opers today make extensive use of third-party libraries like permits a script running in a compartment with the jQuery. Simply importing a library into a page provides privilege to communicate with some set of origins to no isolation whatsoever between the untrusted third-party confer those privileges on another compartment, then code and any sensitive data within the page. Developers relinquish those privileges itself. of applications that process sensitive data want the conve- In the next section, we describe COWL, a new confine- nience of reusing popular libraries. But such reuse risks ment system that satisfies these design goals. exfiltration of sensitive data by these untrusted libraries. Note that because jQuery requires access to the content 3 THE COWL CONFINEMENT SYSTEM of the entire page that uses it, we cannot isolate jQuery The COWL confinement system extends the browser se- in a separate compartment from the parent’s, as we did curity model while leaving the browser fully compatible for the password-checker example. Instead, we observe with today’s “legacy” web applications.4 Under COWL, that jQuery demands a design that is a mirror image of the browser treats a page exactly like a legacy browser that for confining the password checker: we place the does unless the page executes a COWL API operation, trusted code for a page in a separate compartment and at which point the browser records that page as running deem the rest of the page (including the untrusted jQuery in confinement mode, and all further operations by that code) as untrusted. The trusted code can then communi- page are subject to confinement by COWL. COWL aug- cate with remote origins and inject sensitive data into the ments today’s web browser with three primitives, all of untrusted page, but the untrusted page (including jQuery) which appear in the simple password-checker application cannot communicate with remote origins (and thus can- example in Figure 2. not exfiltrate sensitive data within the untrusted page). Labeled browsing contexts enforce MAC-based con- This refactoring highlights the need for a confinement finement of JavaScript at the granularity of a context (e.g., system that supports delegation and dropping privilege: a worker or iframe). The rectangular frames in Figure 2 a page should be able to create a compartment, confer are labeled contexts. As contexts may be nested, labeled its privileges to communicate with remote origins on that browsing contexts allow hierarchical confinement, whose compartment, and then give these privileges up. importance for supporting nesting of untrusted libraries We note further that any library author may wish to we discussed in Section 2.2. reuse functionality from another untrusted library. Accord- When one browsing context sends sensitive informa- ingly, to allow the broadest reuse of code, the browser tion to another, a sending context can use labeled commu- should support hierarchical confinement—the primitives nication to confine the potentially untrusted code receiv- for confining untrusted code should allow not only a sin- ing the information. This enables symmetric confinement, gle level of confinement (one trusted context confining whose importance in building applications that compose one untrusted context), but arbitrarily many levels of con- mutually distrusting scripts we articulated in Section 2.2. finement (one trusted context confining an untrusted one, In Figure 2, the arrows between compartments indicate that in turn confines a further untrusted one, etc.). labeled communication, where a subscript on the communicated data denotes the data’s label. 2.3 Design Goals COWL may grant a labeled browsing context one or We have briefly introduced four motivating web applica- more privileges, each with respect to an origin, and each tions that achieve rich functionality by combining code of which reflects trust that the scripts executing within from one or more untrusted parties. The privacy chal- lenges that arise in such applications are unfortunately 4In prior work, we described how confinement can subsume today’s unaddressed by status-quo browser security policies, such browser security primitives, and advocated replacing them entirely with a clean-slate, confinement-based model [49]. In this paper, we instead as the SOP. These applications clearly illustrate the need prioritize incremental deployability, which requires coexistence along- for robust yet flexible confinement for untrusted code in side the status quo model.

USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) 135 that context will not violate the secrecy and integrity of example, a context labeled amazon.com, mint.com that origin’s data, e.g., because the browser retrieved can send messages to one labeled amazon.com ∧ them from that origin. A privilege authorizes scripts chase.com, mint.com , since the latter is trusted to within a context to execute certain operations, such as preserve the privacy of amazon.com (and chase.com). declassification and delegation, whose abuse would per- However, communication in the reverse direction is not mit the release of sensitive information to unauthorized possible since it may violate the privacy of chase.com. parties. In COWL, we express privilege in terms of ori- In the rest of this paper, we limit our discussion to secrecy gins. The crown icon in the left compartment in Figure 2 and only comment on integrity where relevant; we refer denotes that this compartment may execute privileged op- the interested reader to [33] for a full description of the erations on data labeled with the origin fb.com—more label model. succinctly, that the compartment holds the privilege for A context can freely raise its label, i.e., change its label fb.com. The compartment uses that privilege to remain to any label that is more restricting, in order to receive a unconfined by declassifying the checker response labeled message from an otherwise prohibited context. Of course, fb.com. in raising its label to read more sensitive data from an- We now describe these three constructs in greater detail. other context, the context also becomes more restricted 3.1 Labeled Browsing Contexts in where it can write. For example, a Mint context labeled amazon.com can raise its label to amazon.com A COWL application consists of multiple labeled contexts. chase.com to read bank statements, but only at the ∧ Labeled contexts extend today’s browser contexts, used to cost of giving up its ability to communicate with Ama- isolate iframes, pages, etc., with MAC labels. A context’s zon (or, for that matter, any other) servers. When creating label specifies the security policy for all data within the a new context, code can impose an upper bound on the context, which COWL enforces by restricting the flow of context’s label to ensure that untrusted code cannot raise information to and from other contexts and servers. its label and read data above this clearance. This notion As we have proposed previously [33, 49], a label is a of clearance is well established [14, 17, 34, 35, 51]; we pair of boolean formulas over origins: a secrecy formula discuss its relevance to covert channels in Section 7. specifying which origins may read a context’s data, and As noted, COWL allows a labeled context to create ad- an integrity formula specifying which origins may write ditional labeled contexts, much as today’s browsing con- it. For example, only Amazon or Chase may read data la- texts can create sub-compartments in the form of iframes, beled amazon.com chase.com, amazon.com , and ∨ workers, etc. This functionality is crucial for compart- only Amazon may modify it.5 Amazon could assign mentalizing a system hierarchically, where the developer this label to its order history page to allow a Chase- places code of different degrees of trustworthiness in sep- hosted mashup to read the user’s purchases. On the other arate contexts. For example, in the password checker ex- hand, after a third-party mashup hosted by mint.com ample in Section 2.2, we create a child context in which (as described in Section 2.2) reads both the user’s Chase we execute the untrusted checker script. Importantly, how- bank statement data and Amazon purchase data, the la- ever, code should not be able to leak information by laun- bel on data produced by the third-party mashup will be dering data through a newly created context. Hence, a amazon.com chase.com, mint.com . This secrecy ∧ newly created context implicitly inherits the current label label component specifies that the data may be sensitive of its parent. Alternatively, when creating a child, the par- to both parties, and without both their consent (see Sec- ent may specify an initial current label for the child that tion 3.3), it should only be read by the user; the integrity is more restrictive than the parent’s, to confine the child label component, on the other hand, permits only code further. Top-level contexts (i.e., pages) are assigned a de- hosted by Mint to modify the resulting data. fault label of public, to ensure compatibility with pages COWL enforces label policies in a MAC fashion by written for the legacy SOP. Such browsing contexts can only allowing a context to communicate with other con- be restricted by setting a COWL-label HTTP response texts or servers whose labels are at least as restricting. header, which dictates the minimal document label the (A server’s “label” is simply its origin.) Intuitively, when browser must enforce on the associated content. a context wishes to send a message, the target must not COWL applications can create two types of context. allow additional origins to read the data (preserving se- First, an application can create standard (but labeled) con- crecy). Dually, the source context must not be writable texts in the form of pages, iframes, workers, etc. Indeed, it by origins not otherwise trusted by the target. That is, the may do so because a COWL application is merely a regu- source must be at least as trustworthy as the target. We say lar web application that additionally uses the COWL API. that such a target label “subsumes” the source label. For It thus is confined by MAC, in addition to today’s web 5 and denote disjunction and conjunction. A comma separates security policies. Note that to enforce MAC, COWL must ∨ ∧ the secrecy and integrity formulas. mediate all pre-existing communication channels—even

136 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) USENIX Association subtle and implicit channels, such as content loading— label as or more restrictive than the sending context’s cur- according to contexts’ labels. We describe how COWL rent label may be specified (modulo its clearance). While does so in Section 5. the receiving context may receive a labeled Blob with no Second, a COWL application can create labeled con- immediate effect on the origins with which it can com- 6 texts in the form of lightweight labeled workers (LWork- municate, it may only inspect the label, not the payload. ers). Like normal workers [44], the API exposed to Only after raising its label as needed may the receiving LWorkers is minimal; it consists only of constructs for context read the payload. communicating with the parent, the XHR constructor, and Labeled Blobs simplify building applications that in- the COWL API. Unlike normal workers, which execute in corporate distrust among contexts. Not only can a sender separate threads, an LWorker executes in the same thread impose confinement on a receiver simply by labeling a as its parent, sharing its event loop. This sharing has the message; a receiver can delay inspecting a sensitive mes- added benefit of allowing the parent to give the child (la- sage until it has completed communication with untrusted beled) access to its DOM, any access to which is treated as origins (as does the checker script in Figure 2). They also both a read and a write, i.e., bidirectional communication. ease the implementation of integrity in applications, as Our third-party library example uses such a DOM worker they allow a context that is not trusted to modify content to isolate the trusted application code, which requires ac- in some other context to serve as a passive conduit for a cess to the DOM, from the untrusted jQuery library. In message from a third context that is so trusted. general, LWorkers—especially when given DOM access— Labeled XHR Messages (Browser–Server) Thus far simplify the isolation and confinement of scripts (e.g., the we have focused on confinement as it arises when two password strength checker) that would otherwise run in a browser contexts communicate. Confinement is of use shared context, as when loaded with script tags. in browser-server communication, too. As noted in Sec- tion 3.1, COWL only allows a context to communicate 3.2 Labeled Communication with a server (whether with XHR, retrieving an image, Since COWL enforces a label check whenever a context or otherwise) when the server’s origin subsumes the con- sends a message, the design described thus far is already text’s label. Upon receiving a request, a COWL-aware symmetric: a source context can confine a target con- web server may also wish to know the current label of the text by raising its label (or a child context’s label) and context that initiated it. For this reason, COWL attaches thereafter send the desired message. To read this mes- the current label to every request the browser sends to a sage, the target context must confine itself by raising its server.7 As also noted in Section 3.1, a COWL-aware web label accordingly. These semantics can make interactions server may elect to label a response it sends the client between contexts cumbersome, however. For example, by including a COWL-label header on it. In such cases, a sending context may wish to communicate with mul- the COWL-aware browser will only allow the receiving tiple contexts, and need to confine those target contexts context to read the XHR response if its current label sub- with different labels, or even confine the same target con- sumes that on the response. text with different labels for different messages. And a Here, again, a context that receives labeled data—in receiving context may need unfettered communication this case from a server—may wish to defer raising its with one or more origins for a time before confining itself label until it has completed communication with other by raising its label to receive a message. In the password- remote origins. To give a context this freedom, COWL checker example application, the untrusted checker script supports labeled XHR communication. When a script in- at the right of Figure 2 exhibits exactly this latter behav- vokes COWL’s labeled XHR constructor, COWL delivers ior: it needs to communicate with untrusted remote ori- the response to the initiating script as a labeled Blob. sketchy.ru gin before reading the password labeled Just as with labeled Blob intra-browser IPC, the script fb.com . is then free to delay raising its label to read the payload Labeled Blob Messages (Intra-Browser) To simplify of the response—and delay being confined—until after communication with confinement, we introduce the la- it has completed its other remote communication. For beled Blob, which binds together the payload of an in- example, in the third-party mashup example, Mint only dividual inter-context message with the label protecting confines itself once it has received all necessary (labeled) it. The payload takes the form of a serialized immutable responses from both Amazon and Chase. At this point object of type Blob [47]. Encapsulating the label with the it processes the data and displays results to the user, but message avoids the cumbersome label raises heretofore it can no longer send requests since doing so may leak necessary in both sending and receiving contexts before a message may even be sent or received. Instead, COWL 6The label itself cannot leak information—COWL still ensures that allows the developer sending a message from a context the target context’s label is at least as restricting as that of the source. to specify the label to be attached to a labeled Blob; any 7COWL also attaches the current privilege; see Section 3.3.

USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) 137 information.8 context holds a privilege, code executing in that context 3.3 Privileges will, with the exception of sending a message, always attempt to use it.9 COWL, however, lets code control the While confinement handily enforces secrecy, there are use of privileges by allowing code to get and set the under- occasions when an application must eschew confinement lying context’s privileges. Code can drop privileges by set- in order to achieve its goals, and yet can uphold secrecy ting its context’s privileges to null. Dropping privileges while doing so. For example, a context may be confined is of practical use in confining closely coupled untrusted with respect to some origin (say, a.com) as a result of libraries like jQuery. Setting privileges, on the other hand, having received data from that origin, but may need to increases the trust placed in a context by authorizing it send an encrypted version of that data to a third-party ori- act on behalf of origins. This is especially useful since gin. Doing so does not disclose sensitive data, but COWL COWL allows one context to delegate its privileges (or would normally prohibit such an operation. In such sit- a subset of them) to another; this functionality is also uations, how can a context declassify data, and thus be instrumental in confining untrusted libraries like jQuery. permitted to send to an arbitrary recipient, or avoid the Finally, COWL also allows a context to create privileges recipient’s being confined? for fresh origins, i.e., unique origins that do not have a COWL’s privilege primitive enables safe declassifica- real protocol (and thus do not map to real servers). These tion. A context may hold one or more privileges, each fresh origins are primarily used to completely confine a with respect to some origin. Possession of a privilege for context: the sender can label messages with such an ori- an origin by a context denotes trust that the scripts that gin, which upon inspection will raise the receiver’s label execute within that context will not compromise the se- to this “fake” origin, thereby ensuring that it cannot com- crecy of data from that origin. Where might such trust municate except with the parent (which holds the fresh come from (and hence how are privileges granted)? Under origin’s privilege). the SOP, when a browser retrieves a page from a.com, any script within the context for the page is trusted not 4 APPLICATIONS to violate the secrecy of a.com’s data, as these scripts In Section 2.2, we characterized four applications and are deemed to be executing on behalf of a.com. COWL explained why the status-quo web architecture cannot makes the analogous assumption by granting the privilege accommodate them satisfactorily. We then described the for a.com to the context that retrieves a page from a.com: COWL system’s new browser primitives. We now close scripts executing in that context are similarly deemed to the loop by demonstrating how to build the aforemen- be executing on behalf of a.com, and thus are trusted tioned applications with the COWL primitives. not to leak a.com’s data to unauthorized parties—even Encrypted Document Editor The key feature needed though they can declassify data. Only the COWL run- by an encrypted document editor is symmetric confine- time can create a new privilege for a valid remote origin ment, where two mutually distrusting scripts can each upon retrieval of a page from that origin; a script cannot confine the other’s use of data they send one another. synthesize a privilege for a valid remote origin. Asymmetrically conferring COWL privileges on the dis- To illustrate the role of privileges in declassification, trusting components is the key to realizing this applica- consider the encrypted Google Docs example application. tion. In the implementation of this application atop COWL, Figure 3 depicts the architecture for an encrypted docu- code executing on behalf of eff.org (i.e., in a compartment editor. The editor has three components: a compo- ment holding the eff.org privilege) with a current label nent which has the user’s Google Docs credentials and eff.org gdoc.com is permitted to send messages ∧ communicates with the server (gdoc.com), the editor to a context labeled gdoc.com . Without the eff.org proper (also gdoc.com), and the component that per- privilege, this flow would not be allowed, as it may leak forms encryption (eff.org). COWL provides privacy as the EFF’s information to Google. follows: if eff.org is honest, then COWL ensures that Similarly, code can declassify information when unla- the cleartext of the user’s document is not leaked to any beling messages. Consider now the password checker ex- origin. If only gdoc.com is honest, then gdoc.com may ample application. The left context in Figure 2 leverages be able to recover cleartext (e.g., the encryptor may have its fb.com privilege to declassify the password strength used the null “cipher”), but the encryptor should not be result, which is labeled with its origin, to avoid (uneces- able to exfiltrate the cleartext to anyone else. sarily) raising its label to fb.com. COWL generally exercises privileges implicitly: if a How does execution of the encrypted document editor proceed? Initially, gdoc.com downloads (1) the en- 8To continuously process data in “streaming” fashion, one may partition the application into contexts that poll Amazon and Chase’s 9 While the alternative approach of explicit exercise of privileges servers for new data and pass labeled responses to the confined context (e.g., when registering an onmessage handler) may be safer [23, 34, that processes the payloads of the responses. 51], we find it a poor fit with existing asynchronous web APIs.

8 138 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) USENIX Association 2$ 2$ eﬀ.org$ jquery.com$ KEY$ 3$ 2$

4$ 2$ [EKEY(doc)]$gdoc.com$ 1$ 2$ 3$ 2$ unq0$ public$ public$ gdoc.com$ public$ public$ gdoc.com$ eﬀ.org$ a.com$ a.com$ unq0$ 2$ unq0$ 2$

DOM$ DOM$ DOM$ crypto$ app#TCB# 4$ 2$ 5$ [doc]$ 2$ 1$ gdoc.com eff.org$ Figure 5: Privilege separation and library confinement. 2$ EKEY(doc)$ gdoc.com$ gdoc.com$ eff.org$ data and fully trust that origin not to disclose the data, or gdoc.com$ deny the other origin access to the data altogether. Under COWL, however, a server could CORS-whitelist a foreign DOM$ editor$ origin to permit that origin to read its data, and by setting a label on its response, be safe in the knowledge that Figure 3: Encrypted document editor architecture. COWL would appropriately confine the foreign origin’s 2$ scripts in the browser. 2$ Figure 4 depicts an application that reconciles a user’s amazon.com$ 3$ 2$ public$ chase.com$ Amazon purchases and bank statement. Here, Chase and mint.com$ Amazon respectively expose authenticated read-only APIs amazon.com$ chase.com$ for bank statements and purchase histories that whitelist 1$ 1$ 2$ 2$ DOM$ known applications’ origins, such as mint.com, but set MAC labels on responses.10 As discussed in Section 7, Figure 4: Third-party mashup under COWL. with MAC in place, COWL allows users to otherwise augment CORS by whitelisting foreign origins on a per- crypted document from Google’s servers. As the docu- origin basis. The mashup makes requests to both web ment is encrypted, it opens an iframe to eff.org, with sites using labeled XHR (1) to receive the bank statement initial label public so it can communicate with the and purchase history as labeled Blobs. Once all of the in- eff.org server and download the private key (2) which formation is received, the mashup unlabels the responses will be used to decrypt the document. Next, it sends and raises its context’s label accordingly (2–3); doing so the encrypted document as a labeled Blob, with the la- restricts communication to the web at large. bel gdoc.com (3); the iframe unlabels the Blob and raises its label (4) so it can decrypt the document. Finally, Note that in contrast to when solely using CORS, by the iframe passes the decrypted document (labeled as setting MAC labels on responses, Chase and Amazon need not trust Mint to write bug-free code—COWL con- gdoc.com eff.org ) to the iframe (5) implementing ∧ the editor proper. fines the Mint code to ensure that it cannot arbitrarily leak sensitive data. As we discuss in Section 7, however, To save the document, these steps proceed in reverse: a malicious Mint application could potentially leak data the editor sends a decrypted document to the encryptor (5), through covert channels. We emphasize that COWL nev- which encrypts it with the private key. Next, the critical ertheless offers a significant improvement over the status step occurs: the encryptor exercises its privileges to send quo, in which, e.g., users give their login credentials to a labeled blob of the encrypted document which is only Mint, and thus not only trust Mint to keep their bank labeled gdoc.com (3). Since the encryptor is the only statements confidential, but also not to steal their funds! compartment with the eff.org privilege, all documents must pass through it for encryption before being sent Untrusted Third-Party Library COWL can confine elsewhere; conversely, it itself cannot exfiltrate any data, tightly coupled untrusted third-party libraries like jQuery as it is confined by gdoc.com in its label. by delegating privileges to a trusted context and subse- We have implemented a password manager atop COWL quently dropping them from the main page. In doing so, that lets users safely store passwords on third-party web- COWL completely confines the main page, and ensures accessible storage. We elide its detailed design in the that it can only communicate with the trusted and uncon- interest of brevity, and note only that it operates similarly fined context. Here, the main page may start out with to the encrypted document editor. sensitive data in context, or alternatively, receive it from Third-Party Mashup Labeled XHR as composed with the trusted compartment. CORS is central to COWL’s support for third-party 10On authentication: note that when the browser sends any XHR mashups. Today’s CORS policies are DAC-only, such (labeled or not) from a foreign origin to origin chase.com, it still that a server must either allow another origin to read its includes any cookies cached for chase.com in the request.

USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) 139 interface Label : Channel Mechanism Label Label(String) postMessage Cross-compartment wrappers11 Label and(String or Label) DOM window properties Cross-compartment wrappers Label or(String or Label) Content loading CSP XHR CSP + DOM interposition bool subsumes(Label [,Privilege]) Browser storage SOP + CSP (sandbox) interface Privilege : Other (e.g., iframe height) DOM interposition Privilege FreshPrivilege() Privilege combine(Privilege) Table 1: Confining code from exfiltrating data using existing browser mechanisms. readonly attribute Label asLabel (a) Labels and privileges. fox implementation and only describe the Chromium one where the two diverge non-trivially. interface LabeledBlob : readonly attribute Label label 5.1 Labeled Browsing Contexts readonly attribute Blob blob Gecko’s existing isolation model relies on JavaScript com- (b) Labeled Blobs. partments, i.e., disjoint JavaScript heaps, both for effi- cient garbage collection and security isolation [40]. To interface COWL : achieve isolation, Gecko performs all cross-compartment static void enable() communication (e.g., postMessage between iframes) static attribute Label label through wrappers that implement the object-capability static attribute Label clearance membrane pattern [21, 22]; membranes enable sound rea- static attribute Privilege privilege soning about “border crossing” between compartments. interface LWorker : Wrappers ensure that an object in one compartment can LWorker LWorker(String, Label never directly reference another object in a different com- [, Privilege, object]) partment. Wrappers also include a security policy, which postMessage(object) enforces all inter-compartment access control checks spec- attribute EventHandler onmessage ified by the SOP. Security decisions are made with respect (c) Labeled compartments. to a compartment’s security principal, which contains the Figure 6: COWL programming interface in simplified WebIDL. origin and CSP of the compartment. Figure 5 shows how to use COWL to confine the un- Since COWL’s security model is very similar to this trusted jQuery library referenced by a web page. The goal existing model, we can leverage these wrappers to intro- is to establish a separate DOM worker with the a.com duce COWL’s new security policies. We associate a label, privilege, while the main browsing context runs jQuery in clearance, and privilege with each compartment along- confined fashion—without privileges or the ability to talk side the security principal. Wrappers consider all of these to the network. Initially the main browsing context holds properties together when making security decisions. the a.com privilege. The page generates a fresh origin Intra-Browser Confinement As shown in Table 1, we unq0 and spawns a DOM worker (1), delegating it both rely on wrappers to confine cross-compartment communi- privileges. The main context then drops its privileges and cation. Once confinement mode is enabled, we “recom- raises its label to unq0 (2). Finally, the trusted worker pute” all cross-compartment wrappers to use our MAC downloads jQuery (3) and injects the script content into wrapper policy and thereby ensure that all subsequent the main context’s DOM (4). When the library is loaded, cross-compartment access is mediated not only by the the main context becomes untrusted, but also fully con- SOP, but also by confinement. For postMessage, our fined. As the trusted DOM worker holds both privileges, policy ensures that the receiver’s label subsumes that of it can freely modify the DOM of the main context, as well the sender (taking the receiver’s privileges into consider- as communicate with the wider web. One may view this ation); otherwise the message is silently dropped. For a DOM worker as a firewall between the page proper (with cross-compartment DOM property access, we addition- the untrusted library) and the rest of the world. ally check that the sender’s label subsumes that of the receiver—i.e., that the labels of the compartments are 5 IMPLEMENTATION equivalent after considering the sender’s privileges (in addition to the same-origin check performed by the SOP). We implemented COWL in Firefox 31.0a1 and Chromium Blink’s execution contexts (the dual to Gecko’s com- 31.0.1612.0. Because COWL operates at a context granu- partments) do not rely on wrappers to enforce cross- larity, it admits an implementation as a new DOM-level context access control. Instead, Blink implements the API for the Gecko and Blink layout engines, without any changes to the browsers’ JavaScript engines. Figure 6 11 Since the Chromium architecture does not have cross-compartment shows the core parts of this API. We focus on the Fire- wrappers, we modify the DOM binding code to insert label checks.

10 140 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) USENIX Association SOP security checks in the DOM binding code for a lim- Firefox Chromium ited subset of DOM elements that may allow cross-origin access. Since COWL policies are more ﬁne-grained, we

modified the binding code to extend the security checks to vanilla unlabeled labeled vanilla unlabeled labeled all DOM objects and also perform label checks when con- New iframe 14.4 14.5 14.4 50.6 48.7 51.8 finement mode is enabled. Unfortunately, without wrap- New worker 15.9 15.4 0.9† 18.9 18.9 3.3† pers, shared references cannot efficiently be revoked (i.e., Iframe comm. 0.11 0.11 0.12 0.04 0.04 0.04 without walking the heap). Hence, before enabling con- XHR comm 3.5 3.6 3.7 7.0 7.4 7.2 finement mode, a page can create a same-origin iframe Worker comm. 0.20 0.24 0.03‡ 0.07 0.07 0.03‡ with which it shares references, and the iframe can there- Micro-benchmarks, in milliseconds. after leak any data from the parent even if the latter’s Table 2: label is raised. To prevent this eventuality, our current of COWL by measuring the cost of our new primitives Chromium API allows senders to disallow unlabeling as well as their impact on legacy web sites that do not Blobs if the target created any children before entering use COWL’s features. Our experiments consist of micro- confinement mode. benchmarks of API functions and end-to-end benchmarks Our implementations of LWorkers, whose API appears of our example applications. We conducted all measure- in Figure 6c, reuse labeled contexts straightforwardly. ments on a 4-core i7-2620M machine with 16GB of RAM In fact, the LWorker constructor simply creates a new running GNU/Linux 3.13. The browser retrieved appli- compartment with a fresh origin that contains a fresh cations from the Node.js web server over the loopback JavaScript global object to which we attach the XHR con- interface. We note that these measurements are harsh for structor, COWL API, and primitives for communicating COWL, in that they omit network latency and the com- with the parent (e.g., postMessage). Since LWorkers plex intra-context computation and DOM rendering of may have access to their parents’ DOM, however, our real-world applications, all of which would mask COWL’s wrappers distinguish them from other contexts to bypass overhead further. Our key findings include: SOP checks and only restrict DOM access according to COWL’s latency impact on legacy sites is negligible. MAC. This implementation is very similar to the content Confining code with LWorkers is inexpensive, espe- scripts used by Chrome and Firefox extensions [10, 26]. cially when compared to iframes/Workers. Indeed, Browser-Server Confinement As shown in Table 1, we the performance of our end-to-end confined password confine external communication (including XHR, content checker is only 5 ms slower than that of an inlined loading, and navigation) using CSP. While CSP alone is script version. insufficient for providing flexible confinement,12 it suf- COWL’s incurs low overhead when enforcing confine- ficiently addresses our external communication concern ment on mashups. The greatest overhead observed is by precisely controlling from where a page loads content, 16% (for the encrypted document editor). Again, the performs XHR requests to, etc. To this end, we set a cus- absolute slowdown of 16 ms is imperceptible by users. tom CSP policy whenever the compartment label changes, e.g., with COWL.label. For instance, if the effective com- 6.1 Micro-Benchmarks partment label is Label("https://bank.ch").and Context Creation Table 2 shows micro-benchmarks for ("https://amazon.com"), all the underlying CSP di- the stock browsers (vanilla), the COWL browsers with rectives are set to ’none’ (e.g., default-src ’none’), confinement mode turned off (unlabeled), and with con- disallowing all network communication. We also disable finement mode enabled (labeled). COWL adds negligi- navigation with the ’sandbox’ directive [46–48]. ble latency to compartment creation; indeed, except for Browser Storage Confinement As shown in Table 1, LWorkers (†), the differences in creation times are of the we use the sandbox directive to restrict access to storage order of measurement variability. We omit measurements (e.g., cookies and HTML5 local storage [47]), as have of labeled “normal” Workers since they do not differ from other systems [5]. We leave the implementation of labeled those of unlabeled Workers. We attribute COWL’s iframe- storage as future work. creation speedup in Chromium to measurement variability. We note that the cost of creating LWorkers is considerably 6 EVALUATION less than that for “normal” Workers, which run in separate Performance largely determines acceptance of new OS threads (†). browser features in practice. We evaluate the performance Communication The iframe, worker, and XHR communication measurements evaluate the round-trip laten- 12 There are two primary reasons. First, JavaScript code cannot cies across iframes, workers, and the network. For the (yet) modify a page’s CSP. And, second, CSP does not (yet) provide a directive for restricting in-browser communication, e.g., with XHR benchmark, we report the cost of using the labeled postMessage. XHR constructor averaged over 10,000 requests. Our

11 USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) 141 Chromium implementation uses an LWorker to wrap the requires changing the underlying document origin and unmodified XHR constructor, so the cost of labeled XHR recomputing the cross-compartment wrappers and CSP. incorporates an additional cross-context call. As with cre- Third-Party Mashup We implemented a very simple ation, communicating with LWorkers (‡) is considerably third-party mashup application that makes a labeled XHR faster than with “normal” Workers. This speedup arises request to two unaffiliated origins, each of which pro- because a lightweight LWorker shares an OS thread and duces a response containing a 27-byte JSON object with event loop with their parent. a numerical property, and sums the responses together. Labels We measured the cost of setting/getting the cur- The corresponding vanilla app is identical, but uses the rent label and the average cost of a label check in Firefox. normal XHR object. In both cases we use CORS to per- For a randomly generated label with a handful of origins, mit cross-origin access. The Firefox (labeled) workload these operations take on the order of one microsecond. completes in 41 ms, which is 6 ms slower than the vanilla The primary cost is recomputing cross-compartment wrap- version. As in the document editor the slowdown derives pers and the underlying CSP policy, which ends up costing from raising the current label, though in this case only up to 13ms (e.g., when the label is raised from public to a for a single iframe. On Chromium (labeled) the workload third-party origin). For many real applications, we expect completes in 55 ms, 2 ms slower than the vanilla one; raising the current label to be a rare occurrence. Moreover, the main slowdown here derives from our implementing there is much room for optimization (e.g., porting COWL labeled XHR with a wrapping LWorker. to the newest CSP implementation, which sets policies Untrusted Third-Party Library We measured the load 15 faster [19]). time of a banking application that incorporates jQuery and × DOM We also executed the Dromaeo benchmark a library that traverses the DOM to replace phone num- suite [29], which evaluates the performance of core func- bers with links. The latter library uses XHR in attempt to tionality such as querying, traversing, and manipulating leak the page’s content. We compartmentalize the main the DOM, in Firefox and Chromium. We found the per- page into a public outer component and a sensitive iframe formance of the vanilla and unlabeled browsers to be on containing the bank statement. In both compartments, we par: the greatest slowdown was under 4%. place the bank’s trusted code (which loads the libraries) in a trusted labeled DOM worker with access to the page’s 6.2 End-to-End Benchmarks DOM. We treat the rest of the code as untrusted. As our To focus on measuring COWL’s overhead, we compare current Chromium implementation does not yet support our apps against similarly compartmentalized but non- DOM access for LWorkers, we only report measurements secure apps—i.e., apps that perform no security checks. for Firefox. The measured latency on Firefox (labeled) is Password-Strength Checker We measure the average 165 ms, a 5 ms slowdown when compared to the uncon- duration of creating a new LWorker, fetching an 8 KB fined version running on vanilla Firefox. Again, COWL checker script based on [24], and checking a password prevents sensitive content from being exfiltrated and in- sixteen characters in length. The checker takes an average curs negligible slowdown. of 18 ms (averaged over ten runs) on Firefox (labeled), 4 ms less than using a Worker on vanilla Firefox. Similarly, 7 DISCUSSION AND LIMITATIONS the checker running on labeled Chromium is 5 ms faster We now discuss the implications of certain facets of than the vanilla counterpart (measured at 54 ms). In both COWL’s design, and limitations of the system. cases COWL achieves a speedup because its LWorkers User-Configured Confinement Recall that in the status- are cheaper than normal Workers. However, these mea- quo web security architecture, to allow cross-origin shar- surements are roughly 5 ms slower than simply loading ing, a server must grant individual foreign origins access the checker using an unsafe script tag. to its data with CORS in an all-or-nothing, DAC fash- Encrypted Document Editor We measure the end-to- ion. COWL improves this state of affairs by allowing a end time taken to load the application and encrypt a 4 COWL-aware server to more finely restrict how its shared KB document using the SJCL AES-128 library [32]. The data is disseminated—i.e., when the server grants a for- total run time includes the time taken to load the docu- eign origin access to its data, it can confine the foreign ment editor page, which in turn loads the encryption-layer origin’s script(s) by setting a label on responses it sends iframe, which further loads the editor proper. On Firefox the client. (labeled) the workload completes in 116 ms; on vanilla Unfortunately, absent a permissive CORS header that Firefox, a simplified and unconfined version completes whitelists the origins of applications that a user wishes in 100ms. On Chromium, the performance measurements to use, the SOP prohibits foreign origins from reading were comparable; the completion time was within 1ms responses from the server, even in a COWL-enabled of 244ms. The most expensive operation in the COWL- browser. Since a server’s operator may not be aware of enabled Firefox app is raising the current label, since it all applications its users may wish to use, the result is

142 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) USENIX Association usually the same status-quo unpalatable choice between we recognize this as a limitation of COWL that must be functionality and privacy—e.g., give one’s bank login communicated to the end-user. credentials to Mint, or one cannot use the Mint appli- A trustworthy developer can leverage COWL’s support cation. For this reason, our COWL implementation lets for clearance when compartmentalizing his application to browser users augment CORS by configuring for an origin ensure that only code that actually relies on cross-origin (e.g., chase.com) any foreign origins (e.g., mint.com, data has access to it. Clearance is a label that serves as an benjamins.biz) they wish to additionally whitelist. In upper bound on a context’s current label. Since COWL en- turn, COWL will confine these client-whitelisted origins sures that the current label is adjusted according to the sen- (e.g., mint.com) by labeling every response from the sitivity of the data being read, code cannot read (and thus configured origin (chase.com). COWL obeys the server- leak) data labeled above the clearance. Thus, Mint can supplied label when available and server whitelisting is assign a “low” clearance to untrusted third-party libraries, not provided. Otherwise, COWL conservatively labels the e.g., to keep chase.com’s data confidential. These li- response with a fresh origin (as described in Section 3.3). braries will then not be able to leak such data through The latter ensures that once the response has been in- covert channels, even if they are malicious. spected, the code cannot communicate with any server, Expressivity of Label Model COWL uses DC la- including at the same origin, since such requests carry bels [33] to enforce confinement according to an infor- the risks of self-exfiltration [11] and cross-site request mation flow control discipline. Although this approach forgery [39]. captures a wide set of confinement policies, it is not ex- Covert Channels In an ideal confinement system, it pressive enough to handle policies with a circular flow of would always be safe to let untrusted code compute on information [6] or some policies expressible in more pow- sensitive data. Unfortunately, real-world systems such erful logics (e.g., first order logic, as used by Nexus [30]). as browsers typically exhibit covert channels that mali- DC labels are, however, as expressive as other popular cious code may exploit to exfiltrate sensitive data. Since label models [25], including Myers and Liskov’s Decen- COWL extends existing browsers, we do not protect tralized Label Model [27]. Our experience implementing against covert channel attacks. Indeed, malicious code security policies with them thus far suggests they are can leverage covert channels already present in today’s expressive enough to support featureful web applications. browsers to leak sensitive information. For instance, a We adopted DC labels largely because their fit with malicious script within a confined context may be able to web origins pays practical dividends. First, as developers modulate sensitive data by varying rendering durations. A already typically express policies by whitelisting origins, less confined context may then in turn exfiltrate the data we believe they will find DC labels intuitive to use. Sec- to a remote host [20]. It is important to note, however, ond, because both DC labels and today’s web policies that COWL does not introduce new covert channels— are defined in terms of origins, the implementation of our implementations re-purpose existing (software-based) COWL can straightforwardly reuse the implementation browser isolation mechanisms (V8 contexts and Spider- of existing security mechanisms, such as CSP. Monkey compartments) to enforce MAC policies. More- over, these MAC policies are generally more restricting 8 RELATED WORK than existing browser policies: they prevent unauthorized Existing browser confinement systems based on informa- data exfiltration through overt channels and, in effect, tion flow control can be classified either as fine-grained or force malicious code to resort to using covert channels. coarse-grained. The former associate IFC policies with The only fashion in which COWL relaxes status-quo individual objects, while the latter associate policies with browser policies is by allowing users to override CORS to entire browsing contexts. We compare COWL to previ- permit cross-origin (labeled) sharing. Does this function- ously proposed systems in both categories, then contrast ality introduce new risks? Whitelisting is user controlled the two categories’ overall characteristics. (e.g., the user must explicitly allow mint.com to read Coarse-grained IFC COWL shares many features with amazon.com and chase.com data), and code reading existing coarse-grained systems. BFlow [50], for example, cross-origin data is subject to MAC (e.g., mint.com can- allows web sites to enforce confinement policies stricter not arbitrarily exfiltrate the amazon.com or chase.com than the SOP via protection zones—groups of iframes data after reading it). In contrast, today’s mashups like sharing a common label. However, BFlow cannot me- mint.com ask users for their passwords. COWL is diate between mutually distrustful principals—e.g., the strictly an improvement: under COWL, when a user de- encrypted document editor is not directly implementable cides to trust a mashup integrator such as mint.com, she with BFlow. This is because only asymmetric confinement only trusts the app to not leak her data through covert chan- is supported—a sub-frame cannot impose any restrictions nels. Nevertheless, users can make poor security choices. on its parent. For the same reasons, BFlow cannot support Whitelisting malicious origins would be no exception; applications that require security policies more flexible

USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) 143 than the SOP, such as our third-party mashup example. (non-compartmentalized) JavaScript code, one could de- These differences reflect different goals for the two sys- ploy JSFlow within a COWL context. tems. BFlow’s authors set out to confine untrusted third- Sandboxing The literature on sandboxing and secure party scripts, while we also seek to support applications subsets of JavaScript is rich, and includes Caja [1], that incorporate code from mutually distrusting parties. BrowserShield [28], WebJail [37], TreeHouse [18], More recently, Akhawe et al. propose the data-confined JSand [4], SafeScript [36], Defensive JavaScript [9], and sandbox (DCS) system [5], which allows pages to inter- Embassies [16]). While our design has been inspired by cept and monitor the network, storage, and cross-origin some of these systems (e.g., TreeHouse), the usual goals channels of data: URI iframes. The limitation to data: of these systems are to mediate security-critical opera- URI iframes means DCS cannot confine the common case tions, restrict access to the DOM, and restrict communica- of a service provided in an iframe [31]. Like BFlow, DCS tion APIs. In contrast to the mandatory nature of confine- does not offer symmetric confinement, and does not incor- ment, however, these systems impose most restrictions in porate functionality to let developers build applications discretionary fashion, and are thus not suitable for build- like third-party mashups. ing some of the applications we consider (in particular, Fine-grained IFC Per-object-granularity IFC makes it the encrypted editor). Nevertheless, we believe that access easier to confine untrusted libraries that are closely cou- control and language subsets are crucial complements to pled with trusted code on a page (e.g., jQuery) and avoid confinement for building robustly secure applications. the problem of over-tainting, where a single context accu- mulates taint as it inspects more data. 9 CONCLUSION JSFlow [15] is one such fine-grained JavaScript IFC system, which enforces policies by executing JavaScript Web applications routinely pull together JavaScript con- in an interpreter written in JavaScript. This approach in- tributed by parties untrusted by the user, as well as by curs a two order of magnitude slowdown. JSFlow’s au- mutually distrusting parties. The lack of confinement for thors suggest that this cost makes JSFlow a better fit for untrusted code in the status-quo browser security archi- use as a development tool than as an “always-on” privacy tecture puts users’ privacy at risk. In this paper, we have system for users’ browsers. Additionally, JSFlow does not presented COWL, a label-based MAC system for web support applications that rely on policies more flexible browsers that preserves users’ privacy in the common than the SOP, such as our third-party mashup example. case where untrusted code computes over sensitive data. COWL affords developers flexibility in synthesizing web The FlowFox fine-grained IFC system [12] enforces applications out of untrusted code and services while pre- policies with secure-multi execution (SME) [13]. SME serving users’ privacy. Our positive experience building ensures that no leaks from a sensitive context can leak into four web applications atop COWL for which privacy had a less sensitive context by executing a program multiple previously been unattainable in status-quo web browsers times. Unlike JSFlow and COWL, SME is not amenable suggests that COWL holds promise as a practical plat- to scenarios where declassification plays a key role (e.g., form for preserving privacy in today’s pastiche-like web the encrypted editor or the password manager). FlowFox’s applications. And our measurements of COWL’s perfor- labeling of user interactions and metadata (history, screen mance overhead in the Firefox and Chromium browsers size, etc.) do allow it to mitigate history sniffing and suggest that COWL’s privacy benefits come at negligible behavior tracking; COWL does not address these attacks. end-to-end cost in performance. While fine-grained IFC systems may be more con- venient for developers, they impose new language se- CKNOWLEDGEMENTS mantics for developers to learn, require invasive modi- A fications to the JavaScript engine, and incur greater per- We thank Bobby Holley, Blake Kaplan, Ian Melven, Gar- formance overhead. In contrast, because COWL repur- ret Robinson, Brian Smith, and Boris Zbarsky for helpful poses familiar isolation constructs and does not require discussions of the design and implementation of COWL. JavaScript engine modifications, it is relatively straight- We thank Stefan Heule and John Mitchell for useful com- forward to add to legacy browsers. It also only adds over- ments on formal aspects of the design. And we thank head to cross-compartment operations, rather than to all our shepherd Mihai Budiu and the anonymous review- JavaScript execution. The typically short lifetime of a ers for their helpful comments. This work was funded browsing context helps avoid excessive accumulation of by DARPA CRASH under contract #N66001-10-2-4088, taint. We conjecture that coarse-grained and fine-grained by the EPSRC under grant EP/K032542/1, the Swedish IFC are equally expressive, provided one may use arbi- research agencies VR and STINT, the Barbro Osher Pro trarily many compartments—a cost in programmer con- Suecia foundation, and by multiple gifts from Google (to venience. Finally, coarse- and fine-grained mechanisms Stanford and UCL). Deian Stefan and Edward Z. Yang are not mutually exclusive. For instance, to confine legacy are supported through the NDSEG Fellowship Program.

144 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) USENIX Association REFERENCES [15] D. Hedin, A. Birgisson, L. Bello, and A. Sabelfeld. [1] Google Caja. A source-to-source translator for secur- JSFlow: tracking information ﬂow in JavaScript and ing JavaScript-based web content. http://code. its APIs. In SAC, 2014. google.com/p/google-caja/, 2013. [16] J. Howell, B. Parno, and J. R. Douceur. Embassies: [2] Mint. http://www.mint.com/, 2013. Radically refactoring the Web. In NSDI, 2013. [3] jQuery Usage Statistics: Websites using [17] C. Hrit¸ cu, M. Greenberg, B. Karel, B. C. Pierce, and jQuery. http://trends.builtwith. G. Morrisett. All your ifcexception are belong to us. com/javascript/jQuery, 2014. In Security and Privacy, 2013.

[4] P. Agten, S. Van Acker, Y. Brondsema, P. H. Phung, [18] L. Ingram and M. Walfish. Treehouse: JavaScript L. Desmet, and F. Piessens. JSand: complete client- sandboxes to help web developers help themselves. side sandboxing of third-party JavaScript without In USENIX ATC, 2012. browser modifications. In ACSAC, 2012. [19] C. Kerschbaumer. Faster Content Security Policy [5] D. Akhawe, F. Li, W. He, P. Saxena, and D. Song. (CSP). https://blog.mozilla.org/ Data-confined HTML5 applications. In ESORICS, security/2014/09/10/faster-csp/, 2013. 2014.

[6] L. Badger, D. F. Sterne, D. L. Sherman, K. M. [20] R. Kotcher, Y. Pei, P. Jumde, and C. Jackson. Cross- Walker, and S. A. Haghighat. Practical domain and origin pixel stealing: timing attacks using CSS filters. type enforcement for UNIX. In Security and Pri- In CCS, 2013. vacy, 1995. [21] M. S. Miller. Robust composition: towards a unified [7] A. Barth. The web origin concept. Technical re- approach to access control and concurrency control. port, IETF, 2011. URL https://tools.ietf. PhD thesis, Johns Hopkins University, 2006. org/html/rfc6454. [8] A. Barth, C. Jackson, and J. Mitchell. Securing [22] M. S. Miller and J. S. Shapiro. Paradigm regained: frame communication in browsers. Communications Abstraction mechanisms for access control. In of the ACM, 52(6):83–91, 2009. ASIAN, 2003. [9] K. Bhargavan, A. Delignat-Lavaud, and S. Maffeis. [23] M. S. Miller, K.-P. Yee, and J. Shapiro. Capability Language-based defenses against untrusted browser myths demolished. Technical Report SRL2003-02, origins. In USENIX Security, 2013. Johns Hopkins University Systems Research Labo- ratory, 2003. http://zesty.ca/capmyths/ [10] N. Carlini, A. P. Felt, and D. Wagner. An evaluation usenix.pdf. of the Google Chrome extension security architecture. In USENIX Security, 2012. [24] S. Moitozo. http://www.geekwisdom.com/ js/passwordmeter.js, 2006. [11] E. Y. Chen, S. Gorbaty, A. Singhal, and C. Jackson. Self-exfiltration: The dangers of browser-enforced [25] B. Montagu, B. C. Pierce, and R. Pollack. A theory information flow control. In Web 2.0 Security and of information-flow labels. In CSF, June 2013. Privacy, 2012. [26] Mozilla. Add-on builder and SDK. [12] W. De Groef, D. Devriese, N. Nikiforakis, and https://addons.mozilla.org/en-US/ F. Piessens. FlowFox: a web browser with flexi- developers/docs/sdk/, 2013. ble and precise information flow control. In CCS, 2012. [27] A. C. Myers and B. Liskov. Protecting privacy using the decentralized label model. TOSEM, 9(4), 2000. [13] D. Devriese and F. Piessens. Noninterference through Secure Multi-Execution. In Security and [28] C. Reis, J. Dunagan, H. J. Wang, O. Dubrovsky, and Privacy, 2010. S. Esmeir. Browsershield: Vulnerability-driven fil- tering of dynamic HTML. TWEB, 1(3), Sept. 2007. [14] P. Efstathopoulos, M. Krohn, S. VanDeBogart, C. Frey, D. Ziegler, E. Kohler, D. Mazieres,` [29] J. Reisg. Dromaeo: JavaScript performance testing. F. Kaashoek, and R. Morris. Labels and event pro- http://dromaeo.com/, 2014. cesses in the Asbestos operating system. In OSDI, 2005.

15 USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) 145 [30] E. G. Sirer, W. de Bruijn, P. Reynolds, A. Shieh, [41] H. J. Wang, X. Fan, J. Howell, and C. Jackson. Pro- K. Walsh, D. Williams, and F. B. Schneider. Logical tection and communication abstractions for web attestation: an authorization architecture for trust- browsers in MashupOS. ACM SIGOPS Operating worthy computing. In SOSP, 2011. Systems Review, 41(6), 2007.

[31] S. Son and V. Shmatikov. The postman always [42] WC3. Content Security Policy 1.0. http://www. rings twice: Attacking and defending postMessage w3.org/TR/CSP/, 2012. in HTML5 websites. In NDSS, 2013. [43] WC3. HTML5 web messaging. http://www. [32] E. Stark, M. Hamburg, and D. Boneh. Symmetric w3.org/TR/webmessaging/, 2012. cryptography in JavaScript. In ACSAC, 2009. [44] WC3. Web Workers. http://www.w3.org/ [33] D. Stefan, A. Russo, D. Mazieres,` and J. C. Mitchell. TR/workers/, 2012. Disjunction category labels. In NordSec, 2011. [45] WC3. Cross-Origin Resource Sharing. http:// [34] D. Stefan, A. Russo, J. C. Mitchell, and D. Mazieres.` www.w3.org/TR/cors/, 2013. Flexible dynamic information flow control in Haskell. In Haskell Symposium, 2011. [46] WC3. Content Security Policy 1.1. https://dvcs.w3.org/hg/ [35] D. Stefan, A. Russo, P. Buiras, A. Levy, J. C. content-security-policy/raw-file/ Mitchell, and D. Mazieres.` Addressing covert termi- tip/csp-specification.dev.html, nation and timing channels in concurrent informa- 2013. tion flow systems. In ICFP, 2012. [47] WC3. HTML5. http://www.w3.org/TR/ [36] M. Ter Louw, P. H. Phung, R. Krishnamurti, and html5/, 2013. V. N. Venkatakrishnan. SafeScript: JavaScript trans- formation for policy enforcement. In Secure IT [48] WHATWG. HTML living standard. http:// Systems, 2013. developers.whatwg.org/, 2013. [37] S. Van Acker, P. De Ryck, L. Desmet, F. Piessens, [49] E. Yang, D. Stefan, J. Mitchell, D. Mazieres,` and W. Joosen. WebJail: least-privilege integration P. Marchenko, and B. Karp. Toward principled of third-party components in web mashups. In AC- browser security. In HotOS, 2013. SAC, 2011. [50] A. Yip, N. Narula, M. Krohn, and R. Morris. Privacy- [38] A. Van Kesteren. Cross-Origin Resource Sharing. preserving browser-side scripting with BFlow. In http://www.w3.org/TR/cors/, 2012. EuroSys, 2009. [39] B. Vibber. CSRF token-stealing attack (user.tokens). [51] N. Zeldovich, S. Boyd-Wickizer, E. Kohler, and https://bugzilla.wikimedia.org/ D. Mazieres.` Making information flow explicit in show_bug.cgi?id=34907, 2014. HiStar. In OSDI, 2006. [40] G. Wagner, A. Gal, C. Wimmer, B. Eich, and [52] M. Zelwski. Browser security handbook, M. Franz. Compartmental memory management part 2. HTtp://code.google.com/p/ in a modern web browser. SIGPLAN Notices, 46 browsersec/wiki/Part2, 2011. (11), 2011.

146 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI ’14) USENIX Association