Protection and Communication Abstractions for Web Browsers in MashupOS Helen J. Wang (Microsoft Research), Xiaofeng Fan (Microsoft Research), Jon Howell (Microsoft Research), Collin Jackson (Stanford University) Proc. of the 21st ACM Symposium on Operating Systems Principles (SOSP), 2007 Presented by Fu-Chi Ao

Outline Introduction Principals and Resources Trust Models Among Principals Unauthorized Content and the Sandbox Abstractions The Abstraction for Access-Controlled Content Communication: CommRequest Implementation Evaluation Conclusions and Comments 2009/8/112

Introduction Initial paper at HotOS 2007 – J. Howell, C. Jackson, H. Wang, and X. Fan, “MashupOS: Operating system abstractions for client mashups,” In Proceedings of the Workshop on Hot Topics in Operating Systems, May 2007 Browsers have evolved from a single-principal platform on which one site is browsed at a time to be a multi-principal operating environment – Mutually distrusting Web sites (as principals) interact programmatically in a single page on the client side, sharing the underlying browser resources This resembles the PC operating environment where mutually distrusting users share host resources 2009/8/113

Principals and Resources Principal – OS environment: A user or group – Web environment: The owner of some Web content. With the SOP, a principal on browsers is tied to the ownership of a DNS domain A principal’s resources provided by a browser: BrowserAnalogous to MemoryHeap of script objectsProcess heap memory Persistent StateFew kilobytes of cookies, etc.OS file system Display The HTML DOM that controls the user’s display X Windows resources Network Communications The ability to send and receive messages outside the application OS network facility 4

Insufficiency of the SOP The Same Origin Policy (SOP), an all-or-nothing trust model: – No cross-domain interactions allowed – (External) scripts run with the privilege of the enclosing page Web programmers are forced to make tradeoffs between security and functionality 5 <iframe src=“ <script src=“ X 2009/8/11

The MashupOS Project Design and build a browser-based multi-principal OS Focus of this paper: protection and communication abstractions Protection: – To prevent one principal (domain) from compromising the confidentiality and integrity of other principals  Provide default isolation boundaries Communication: – Allows principals to interact in a controlled manner  Custom and more fine-grained access control across isolation boundaries 2009/8/116

Design Principals Match all common trust levels between content providers and integrators – Provide a full set of abstractions – Enable programmers to build robust and secure services that match their trust expectations Easy adoption and no unintended behavior – Backward compatible – Not have any unintended behavior with existing abstractions 2009/8/117

Trust Relationship between Providers and Integrators i.com Content Semantics AbstractionRun-as 8 p.comi.com Internet HTML XHR X X No Isolated p.com <iframe src=“ X The isolated content runs as the principle of the provider, p.com, and access all resources belonging to the provider p.com and cannot access any of the integrator i.com’s resources 2009/8/11 Access: r/ w a DOM or JavaScript object or function invocations

Trust Relationship between Providers and Integrators i.com Content Semantics AbstractionRun-as 9 p.comi.com Internet Script XHR No Isolated p.com Yes Open i.com <script src=“ The open content runs as the principle of the integrator, i.com, and can access all of i.com’s resources 2009/8/11

Trust Relationship between Providers and Integrators i.com Content Semantics AbstractionRun-as 10 p.comi.com Internet No Isolated p.com Yes Open i.com NoYes X When i.com is not trusted to access the blue content, but the blue content can access i.com, this trust relationship does not really make sense 2009/8/11

Trust Relationship between Providers and Integrators 11 p.comi.com Internet X X XHR None YesNo Unauthorized Unauth X XHR i.com Content Semantics AbstractionRun-as No Isolated p.com Yes Open i.com NoYes Unauthorized content is not authorized to access any domain’s resources. <sandbox src=“ The content should not run as the integrator since the integrator does not grant any resource access to it, and should not run as the provider since the integrator can manipulate the content. 2009/8/11

Trust Relationship between Providers and Integrators 12 None YesNo Unauthorized i.com Content Semantics AbstractionRun-as No Isolated Access- controlled & CommRequest p.com Yes Open i.com NoYes The provider of the access-controlled content still not trust any integrators to access the provider’s content by default, but can use cross-domain communications to provide a subset of content based on the integrator’s credentials. 2009/8/11 p.comi.com Internet XHR X X X Access-controlled content: The isolated content to which the content owner provides access control through cross-domain communications

Unauthorized Content and the Sandbox Abstractions MashupOS enables service providers to publish and integrators to consume unauthorized content, such as third-party content, without liability and over-trusting Through a provider-browser protocol and the and browser abstractions 2009/8/1113

Sandbox for Safe Mashups with Ease 14 // local script to Mashup.com // calling functions in a.js and b.js … X X 2009/8/11

Unauthorized Content and the Sandbox Abstractions (cont’d) The sandboxed content cannot reach out of the sandbox The enclosing page of an open sandbox or the same- domain enclosing page of a private sandbox can access everything inside the sandbox – Access: r/w script global objects, function invocations, modify/create DOM elements inside the sandbox through DOM method calls The enclosing page is unable to pass non-sandbox object references into the sandbox – To prevent code from within the sandbox from following those references out of the sandbox 2009/8/1115

Private Unauthorized Content May belong to a principal in the sense that the unauthorized content is private to the principal and cannot be accessed by other principals Useful for an integrator to integrate open content that the integrator does not trust When the src attribute indicates a path from a different domain (principal), the enclosing page cannot access the content in the sandbox 2009/8/1116

Open Unauthorized Content Allows any principal to access the content directly Useful for providers to provide a service to any integrators while not being liable for it No matter which domain hosts the content, the enclosing page can access the content fully including the HTML content 2009/8/1117

Provider-Browser Protocol for Unauthorized Content Needed for the provider to indicate to browsers that such unauthorized content is not trustworthy and for browsers to forbid rendering (or running) the content in the name of any principal Employ the MIME protocol: – Require unauthorized content providers to prefix their MIME content subtype with x-privateUnauthorized+ or x- openUnauthorized+ – E.g., text/html  text/x-privateUnauthorized+html Content-Type defines the content of the document, and comes in seven pre- defined types, each of which have subtypes. An extension mechanism exists for defining new types and subtypes – Verified that IE and Firefox cannot render these content types with and /8/11

Hosting Third-Party Content as Unauthorized Content Combats cross site scripting attacks in a fundamental way – Put user input into a sandbox – Does not have to sacrifice functionality Helps with Web spam – Discount the score of hyperlinks in third party content 19 <Sandbox src=‘userInput.asp?...escaped input…’> 2009/8/11

The Abstraction for Access-Controlled Content abstraction – A unit of isolation, fault containment, and resource allocation – Used for rendering access-controlled content. CommRequest communication abstraction – Enables controlled communication between s 2009/8/1120

Isolation and Fault Containment: ServiceInstance (1/2) Accounts for commodity resources, as well as a protection boundary, to prevent other domains from compromising the privacy or integrity of the data stored in those resources The HTML file specified by the src tag should contain only a script tag The tag create an isolated environment and associates it with the domain bob.com 2009/8/1121

Isolation and Fault Containment: ServiceInstance (2/2) Memory – Each has its own isolated memory Persistent State – Two s can access the same cookie data iff they belong to the same domain Display – The parent document that created the must allocate a subregion of its own display, called a, and assign the to the child – The code in the controls each display region by manipulating its corresponding DOM tree Network Resources – A can access its principal’s remote data store through XMLHttpRequest based on SOP – s communicate among themselves using CommRequest 2009/8/1122

Flexible Cross-Domain Display: Friv A combination of and – Provides a boundary between a container document and an inner document Isolate the content from separate domains – Allows the child’s layout requirements to flow to the frame in the container Enables the container to adjust its layout to suit the child document Achieves this by providing default handlers that negotiate layout size using the MashupOS local communication primitives 2009/8/1123

Communication: CommRequest (1/4) Communication: Transfer of arbitrary data, eg. XML file Legacy browsers follow the SOP – Enable only communication from the browser-side component to its corresponding server webmail display stocks display webmail.com stocks.com client browser CommRequest /8/1124 The SOP isolates HTML pages and frames based on their source MashupOS supports both SOP(1) and VOP (1, 2, 3) communication patterns

Communication: CommRequest (2/4) Browser-to-server communication – The protocol labels the request with the domain that initiated it – Any participating server verifies the domain initiating the request – Adopt the technique proposed by JSONReuest Requires participating servers to indicate their compliance Tag their replies with a special MIME content type (application/jsonrequest) 2009/8/1125

Communication: CommRequest (3/4) Browser-side communication (across domain) – Bob.com: – Alice.com: server = new CommServer(); server.listenTo(“aPort”, requestHandlerFunction); req = new CommRequest(); req.open (“INVOKE”, “local: req.send (requestData); req.onreadystatechange = function () { …} 2009/8/1126 A from Bob.com may declare a port “aPort”, and register a handler function to receive browser-side messages on that port

Communication: CommRequest (4/4) May be non-adversarial name conflicts from multiple s running in the same browser – Address each instance using DOM relationship Each has a unique ID and can learn the IDs of its parents and children Both Alice’s page and Bob’s page include an instant- messaging gadget from im.com – Set default parameters, or negotiate boundaries The im.com looks up its identifier and registers it as a port name which includes the im.com principal A can finally address its parent Alice’s uses methods on the element to represent the child in the Alice’s DOM 2009/8/1127

Implementation Prototype developed for IE7 and runs on Windows XP SP2 and Windows Server 2003 SPI Only one per No and MIME content types enforcement Modifications made to browser extensions and public interfaces exported by IE Use the existing isolation mechanism, namely frames, as building block 2009/8/1128

Takes the crucial role of implementing our various protection abstractions Interposes DOM object access and update Takes an input HTML stream and outputs a MashupOS- transformed HTML stream to the next software layer in IE Translate new tags into existing tags (iframe and script) 2009/8/1129

Evaluation: Showcase Application PhotoLoc, a photo location service – Mash up Google’s map service and Flickr’s geo- tagged photo gallery service – Map out the locations of photographs taken Trust relationship with Flickr: mutually distrusting Trust relationship with Google map library: Photoloc.com does not want Google’s map library to access all its resources /8/11

PhotoLoc/index.htm function setPhotoLoc(request) { var coordinate = request.body; var latitude = getLatitude (coordinate); var longitude = getLongitude (coordinate); G.map.setCenter(new GLatLng(latitude, longitude), 6); } var svr = new CommServer(); svr.listenTo(“recvLocationPort”, setPhotoLoc); 31 Direct access CommRequest 2009/8/11

ourFlicker.com/newGeoTaggedPhoto/ index.htm function sendLoc() { if ( hasCoordinate ) { var req = new CommRequest(); req.open("INVOKE", "local:parent//recvLocationPort"); var requestBody = createCoordinate (latitude, longitude); req.send(requestBody); } … /8/11

PhotoLoc.com/g.uhtml var map; function createGmapWithDiv() { map = new GMap2(divMap); } … /8/11

Evaluation: Prototype Performance Microbenchmarking for script engine proxy – Negligible overhead for no or moderate DOM manipulations – 33%--82% overhead with heavy DOM manipulations Macrobenchmark measures overall page-loading time using top 500 pages from the top click-through search results of MSN search from 2005 – shows no impact Anticipate in-browser implementation to have low overhead /8/11

Conclusions Provides abstraction for protection and communication on a multi-principal OS The missing protection abstraction: Unauthorized content and – Enable safe mashups with ease – Combats cross-site scripting in a fundamental way CommRequest as a VOP-based communication abstraction for access controlled content across isolation boundaries ServiceInstance for isolation, fault containment, and as the unit of resource allocation Backward Compatible and practical for deployment /8/11

Comments Some complex issues… – Tools to detect whether a browser extension violates the browser’s protection model – Tools for ensuring proper segregation of different content types Resource management, OS facilities that browsers can offer to Web services 2009/8/1136