Privilege Separation in HTML5 Applications

Privilege Separation in HTML5 Applications Devdatta Akhawe, Prateek Saxena, Dawn Song University of California, Berkeley fdevdatta,prateeks,[email protected] Abstract QMail [18] and Google Chrome [19]. In contrast, privilege separation in web applications is harder and comes The standard approach for privilege separation in at a cost. If an HTML5 application wishes to separate web applications is to execute application components its functionality into multiple isolated components, the in different web origins. This limits the practicality of same-origin policy (SOP) mandates that each component privilege separation since each web origin has finan- execute in a separate web origin.1 Owning and main- cial and administrative cost. In this paper, we pro- taining multiple web origins has significant practical ad- pose a new design for achieving effective privilege sep- ministrative overheads. 2 As a result, in practice, the aration in HTML5 applications that shows how appli- number of origins available to a single web application cations can cheaply create arbitrary number of com- is limited. Web applications cannot use the same-origin ponents. Our approach utilizes standardized abstrac- policy to isolate every new component they add into the tions already implemented in modern browsers. We do application. At best, web applications can only utilize not advocate any changes to the underlying browser or sub-domains for isolating components, which does not require learning new high-level languages, which con- provide proper isolation, due to special powers granted trasts prior approaches. We empirically show that we to sub-domains in the cookie and document.domain be- can retrofit our design to real-world HTML5 applica- haviors. tions (browser extensions and rich client-side applica- Recent research [12, 20] and modern HTML5 plat- tions) and achieve reduction of 6x to 10000x in TCB for forms, such as the Google Chrome extension platform our case studies. Our mechanism requires less than 13 (also used for “packaged web applications”), have recog- lines of application-specific code changes and consider- nized the need for better privilege separation in HTML5 ably improves auditability. applications. These systems advocate re-architecting the 1 Introduction underlying browser or OS platform to force HTML5 applications to be divided into a fixed number of compo- Applications written with JavaScript, HTML5 and CSS nents. For instance, the Google Chrome extension frame- constructs (called HTML5 applications) are becoming work requires that extensions have three components, ubiquitous. Rich web applications and web browser ex- each of which executes with different privileges [19]. tensions are examples of HTML5 applications that al- Similarly, recent research proposes to partition HTML5 ready enjoy massive popularity [1, 2]. The introduc- applications in “N privilege rings”, similar to the isolation of browser operating systems [3, 4], and support for tion primitives supported by x86 processors [12]. We HTML5 applications in classic operating systems [5, 6] observe two problems with these approaches. First, the herald the convergence of web and desktop applica- fixed limit on the number of partitions or components tions. However, web vulnerabilities are still pervasive in creates an artificial and unnecessary limitation. Differ- emerging web applications and browser extensions [7], despite immense prior research on detection and mitiga- 1Browsers isolate applications based on their origins. An origin is tion techniques [8–12]. defined as the tuple <scheme, host, port>. In recent browser exten- Privilege separation is an established security prim- sion platforms, such as in Google Chrome, each extension is assigned a unique public key as its web origin. These origins are assigned and itive for providing an important second line of de- fixed at the registration time. fense [13]. Commodity OSes enable privilege separated 2To create new origins, the application needs to either create new applications via isolation mechanisms such as LXC [14], DNS domains or run services at ports different from port 80 and 443. seccomp [15], SysTrace [16]. Traditional applications New domains cost money, need to be registered with DNS servers and are long-lived. Creating new ports for web services does not work: first, have utilized these for increased assurance and secu- network firewalls block atypical ports and Internet Explorer doesn’t rity. Some well-known examples include OpenSSH [17], include the port in determining an application’s origin 1 ent applications require differing number of components, apply this approach to secure Chrome applications, and and a “one-size-fits-all” approach does not work. We our design has influenced the security architecture of up- show that, as a result, HTML5 applications in such plat- coming Chrome applications. forms have large amounts of code running with unneces- In our architecture, HTML5 applications can de- sary privileges, which increases the impact from attacks fine more expressive policies than supported by exist- like cross-site scripting. Second, browser re-design has ing HTML5 platforms, namely the Chrome extension a built-in deployment and adoption cost and it takes sig- platform [19] and the Windows 8 Metro platform [5]. nificant time before applications can enjoy the benefits Google Chrome and Windows 8 rely on applications of privilege separation. declaring install-time permissions that end users can In this paper, we rethink how to achieve privilege sepa- check [23]. Multiple studies have found permission sys- ration in HTML5 applications. In particular, we propose tems to be inadequate: the bulk of popular applications a solution that does not require any platform changes run with powerful permissions [24, 25] and users rarely and is orthogonal to privilege separation architectures en- check install-time permissions [26]. In our architecture, forced by the underlying browsers. Our proposal uti- policy code is explicit and clearly separated, can take lizes standardized primitives available in today’s web into account runtime ordering of privileged accesses, and browsers, requires no additional web domains and im- can be more fine-grained. This design enables expert au- proves the auditability of HTML5 applications. In our ditors, such as maintainers of software application gal- proposal, HTML5 applications can create an arbitrary leries, to reason about the security of applications. In our number of “unprivileged components.” Each compo- case studies, these policies are typically a small amount nent executes in its own temporary origin isolated from of static JavaScript code, which is easily auditable. the rest of the components by the SOP. For any privileged call, the unprivileged components communicate 2 Problem and Approach Overview with a “privileged” (parent) component, which executes Traditional HTML applications execute with the author- in the main (permanent) origin of the web application. ity of their “web origin” (protocol, port, and domain). The privileged code is small and we ensure its integrity The browser’s same origin policy (SOP) isolates differ- by enforcing key security invariants, which we define in ent web origins from one another and from the file sys- Section 3. The privileged code mediates all access to tem. However, applications rarely rely on domains for the critical resources granted to the web application by isolation, due to the costs associated with creating new the underlying browser platform, and it enforces a fine- domains or origins. grained policy on all accesses that can be easily audited. In more recent application platforms, such as the Our proposal achieves the same security benefits in en- Google Chrome extension platform [23], Chrome pack- suring application integrity as enjoyed by desktop appli- aged web application store [1] and Windows 8 Metro ap- cations with process isolation and sandboxing primitives plications [5], applications can execute with enhanced available in commodity OSes [14–16]. privileges. These privileges, such as access to the We show that our approach is practical for exist- geo-location, are provided by the underlying platform ing HTML5 applications. We retrofit two widely used through privileged APIs. Applications utilizing these Google Chrome extensions and a popular HTML5 appli- privileged API explicitly declare their permissions to use cation for SQL database administration to use our design. privileged APIs at install time via manifest files. These In our case studies, we show that the amount of trusted applications are authored using the standard HTML5 fea- code running with full privileges reduces by a factor of tures and web languages (like JavaScript) that web ap- 6 to 10000. Our architecture does not sacrifice any per- plications use; we use the term HTML5 applications to formance as compared to alternative approaches that re- collectively refer to web applications and the aforemen- design the underlying web browser. Finally, our migra- tioned class of emerging applications. tion of existing applications requires minimal changes to Install-time manifests are a step towards better secu- code. For example, in porting our case studies to this rity. However, these platforms still limit the number of new design we changed no more than 13 lines of code application components to a finite few and rely on sep- in any application. Developers do not need to learn new arate origins to isolate them. For example, each Google languages or type safety

Load more