WWW 2008 / Refereed Track: Security and Privacy - Web Client Security April 21-25, 2008 · Beijing, China SMash: Secure Component Model for Cross-Domain Mashups on Unmodified Browsers Frederik De Keukelaere, Sumeer Bhola, Michael Steiner, Suresh Chari, Sachiko Yoshihama {eb41704, sachikoy}@jp.ibm.com, {sbhola, msteiner, schari}@us.ibm.com IBM Tokyo Research Laboratory, Kanagawa, Japan; IBM T.J. Watson Research Center, New York, USA ABSTRACT Mashup applications mix and merge content (data and code) from multiple content providers in a user's browser, to provide high-value web applications that can rival the user exp erience provided by desktop applications. Current browser security models were not designed to supp ort such applications and they are therefore implemented with insecure workarounds. In this pap er, we present a secure comp onent model, where comp onents are provided by different trust domains, and can interact using a communication abstraction that allows ease of sp ecification of a security p olicy. We have develop ed an implementation of this model that works currently in all ma jor browsers, and addresses challenges of communication integrity and frame-phishing. An evaluation of the p erformance of our implementation shows that this approach is not just feasible but also practical. Categories and Sub ject Descriptors: D.2.0 [General]: Protection mechanisms, D.2.11 [Software Architectures]: Information hiding, domain-sp ecific General Terms: Security, design. Keywords: Web 2.0, browser, mashup, comp onent model, phishing. 1. INTRODUCTION Web applications increasingly rely on extensive scripting on the client-side (browser) using readily available JavaScript libraries. One motivation for this is to enable a browser user exp erience comparable to that of desktop applications. The extensive use of scripting on the client side and programming paradigms such as AJAX [14] has also led to the growth of applications, called mashups, which mix and merge content1 coming from different content providers in the browser. Mashups are now prevalent in a numb er of contexts, including news websites, which have integrity requirements, or web email, which handles confidential information. They are essential to an advertising supp orted business model, and for allowing user-generated content in Web 2.0 websites. The tremendous additional value that can b e provided to users by mixing and merging content implies that such applications will eventually b e prevalent in contexts with stricter data 1 We use the term content to refer to active content, i.e., b oth data and JavaScript. security requirements, like consumer banking sites and enterprise applications. Since existing browser security models were defined and develop ed without anticipating such applications, these applications are pushing the b oundaries of current browser security models. Since content in a mashup application can stem from mutually untrusting providers, it is clear that they should b e built on a sound security foundation protecting the interests of the various involved parties such as the content providers and the end-user. For example, consider a mashup application scenario of a car p ortal where information from multiple car dealers, insurance companies and the user's bank could b e combined and co-resident on the user's browser. It is clear that, at a minimum, we want certain security requirements to b e enforced, such as the dealer's scripts not b eing able to modify each others car prices, nor should they b e able to spy on a user's bank account information. The traditional browser security model dictates that content from different origins 2 cannot interact with each other, while content from the same origin can interact without constraints (reading and writing of each others' state). This model does not supp ort mashups, where controlled interaction is desirable. To overcome the no interaction restriction, mashup develop ers typically enable interaction by either (1) using a web application proxy server which fetches the content from different servers and serves it to the mashup, or (2) by directly including code and data from different origins (using