1 / 64

Protection and Communication Abstractions for Web Browsers in MashupOS

Protection and Communication Abstractions for Web Browsers in MashupOS. Helen J. Wang, Xiaofeng Fan, Jon Howell (MSR) Collin Jackson (Stanford) February, 2008. OMash: Enabling Secure Web Mashups via Object Abstractions. Steven Crites, Francis Hsu , Hao Chen UC Davis.

avital
Download Presentation

Protection and Communication Abstractions for Web Browsers in MashupOS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Protection and Communication Abstractions for Web Browsers in MashupOS Helen J. Wang, Xiaofeng Fan, Jon Howell (MSR) Collin Jackson (Stanford) February, 2008

  2. OMash: Enabling Secure Web Mashups via Object Abstractions Steven Crites, Francis Hsu, Hao Chen UC Davis

  3. … but most of all, Samy is my hero

  4. Outline • The problem • The MashupOS project • Protection • Communication • Implementation and demo • Evaluation • Related work • Conclusions

  5. Client Mashups • Web content has evolved from single-principal services to multi-principal services, rivaling that of desktop PCs. • Principal is domain

  6. Browsers Remain Single-Principal Systems • 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 http://integrator.com/ http://integrator.com/ <iframe src=“http://provider.com/p.html”> </iframe> <script src=“http://provider.com/p.js”> </script> X

  7. Same Origin Policy Server a.com    Browser   a.com a.com b.com

  8. What Domains are of the Same Origin? Same origin? web1.acm.org web2.acm.org yes maybe ece.ucdavis.edu cs.ucdavis.edu amazon.co.uk no bbc.co.uk

  9. Insufficiency of the SOP • Sacrifice security for functionality when including an external script without fully trusting it • E.g., iGoogle, Live gadget aggregators’ inline gadget

  10. Insufficiency of the SOP, Cont. • Third-party content sanitization is hard • Cross site scripting (XSS): • Unchecked user input in a generated page • E.g., Samy worm: infected 1 million MySpace.com users in 20 hours • Root cause: • The injected scripts run with the page’s privilege Samy is my hero

  11. Insufficiency of the SOP, Cont. • Sacrifice functionality for security when denying scripts in third-party content • E.g., MySpace.com disallows scripts in user profiles

  12. DNS Insecurity • Client vulnerabilities • DNS rebinding (Jackson et al, CCS 07) • Dynamic Pharming (Karlof et al, CCS 07) • Server vulnerabilities • DNS cache poisoning (Kaminsky, BlackHat 08)

  13. Cross-Site Request Forgery Server a.com Browser b.com a.com

  14. The MashupOS Project • Enable browser to be a multi-principal OS • Focus of this paper: protection and communication abstractions • Protection: • Provide default isolation boundaries • Communications: • Allow service-specific, fine-grained access control across isolation boundaries

  15. Design Principles • Match all common trust levels to balance ease-of-use and security • Goal: enable programmers to build robust services • Non-goal: make it impossible for programmers to shoot themselves in the foot • Easy adoption and no unintended behaviors

  16. Outline • The problem • The MashupOS project • Protection • Communication • Implementation and demo • Evaluation • Related work • Conclusions

  17. A Principal’s Resources • Memory: • heap of script objects including DOM objects that control the display • Persistent state: • cookies, etc. • Remote data access: • XMLHttpRequest

  18. Trust Relationship between Providers and Integrators i.com p.com HTML XHR No No Isolated <Frame> p.com X Internet XHR http://i.com/ X X <iframe src=“http://p.com/c.html”> </iframe>

  19. Trust Relationship between Providers and Integrators i.com p.com Script No No Isolated <Frame> p.com Internet XHR Yes Yes Open <Script> i.com http://i.com/ <script src=“http://p.com/c.js”> </script>

  20. Trust Relationship between Providers and Integrators i.com p.com No No Isolated <Frame> p.com Internet Yes Yes Open <Script> i.com No Yes http://i.com/ X

  21. Trust Relationship between Providers and Integrators i.com p.com Unauth XHR XHR X X No No Isolated <Frame> p.com Internet Yes Yes Open <Script> i.com No Yes http://i.com/ None <Sandbox> <OpenSandbox> Yes No Unauthorized X <sandbox src=“http://p.com/c.html”> </sandbox> Unauthorized content is not authorized to access any principal’s resources.

  22. Properties of Sandbox • Asymmetric access • Access: reading/writing script global objects, function invocations, modifying/creating DOM elements inside the sandbox • Invoking a sandbox’s function is done in the context of the sandbox • setuid (“unauthorized”) before invocation and setuid (“enclosingPagePrincipal) upon exit • The enclosing page cannot pass non-sandbox object references into the sandbox. • Programmers can put needed objects inside the sandbox • Private vs. Open sandboxes

  23. Private Sandbox <sandbox src=“file”> Content if tag not supported </sandbox> • Belongs to a domain and can only be accessed by that domain • E.g., private location history marked on a map • Private sandboxes cannot access one another even when nested • Otherwise, a malicious script can nest another private sandbox and access its private content

  24. Open Sandbox <OpenSandbox src=“file”> Content if tag not supported </OpenSandbox> • Can be accessed by any domain • Can access its descendant open sandboxes --- important for third party service composition • E.g., e-mail containing a map; don’t want an e-mail to tamper hotmail.com; don’t want the map library to tamper the e-mail

  25. Provider-Browser Protocol for Unauthorized Content • Unauthorized content must be sandboxed and must not be renderable by frames • Otherwise, unauthorized content would run as the principal of the frame • MIME protocol seems to be what we want: • Require providers to prefix unauthorized content subtype with x-privateUnauthorized+ or x-openUnauthorized+ • E.g., text/html  text/x-privateUnauthorized+html • Verified that Firefox cannot render these content types with <frame> and <script> • But, IE’s MIME sniffing allows rendering sometimes • Alternative: encraption (e.g., Base64 encoding) • Prevent providers from unintentionally publishing unauthorized content as other types of content: • Constrain sandbox to take only unauthorized content

  26. Key Benefits of Sandbox • Safe mashups with ease • Beneficial to host third-party content as unauthorized content

  27. Sandbox for Safe Mashups with Ease http://Mashup.com/index.htm <script> // local script to Mashup.com // calling functions in a.js and b.js </script> X <script src=“a.com/a.js”> </script> <div id=“displayAreaForA”> … </div> X <script src=“b.com/b.js”> </script>

  28. 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

  29. Outline • The problem • The MashupOS project • Protection • Communication • Implementation & demo • Evaluation • Related work • Conclusions

  30. Communications • Message passing across the isolation boundaries enable custom, fine-grained access control a.com b.com CommRequest CommRequest Unauthorized Isolated Isolated

  31. CommRequest • Server: server = new CommServer(); server.listenTo(“aPort”, requestHandlerFunction); • Client: req = new CommRequest(); req.open (“INVOKE”, “local:http://bob.com//aPort”, isSynchronous); req.send (requestData); req.onreadystatechange = function () { …}

  32. CommRequest vs. XMLHttpRequest • Cross domain • Source labeled • No cookies sent • “Server” can be on client • Reply from remote server tagged with special MIME type • Syntax similar to socket API and XHR

  33. Outline • The problem • The MashupOS project • Protection • Communication • Implementation & demo • Evaluation • Related work • Conclusions

  34. Implementation MashupOS Script Engine Proxy • Use frames as our building blocks, but we apply our access control HTML Layout Engine Script execution DOM object access Script Engine DOM object update MashupOS transformed HTML Original HTML MashupOS MIME Filter

  35. 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 • PhotoLoc doesn’t trust flickr nor gmap

  36. PhotoLoc/index.htm <script> 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); </script> <Sandbox src=”f.uhtml” id=F> </Sandbox> <Sandbox src=”g.uhtml” id=G> </Sandbox> Direct access CommRequest

  37. Demo

  38. 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

  39. Outline • The problem • The MashupOS project • Protection • Communication • Implementation & demo • Evaluation • Related work • Conclusions

  40. Related work • Crockford’s <Module> • Symmetric isolation with socket-like communication with the enclosing page • Wahbe et al’s Software Fault Isolation • Asymmetric access though never leveraged • Primary goal was to avoid context switches for untrusted code in a process • Cox et al’s Tahoma browser operating system uses VM to • Protect the host system from browser and web services • Protect web applications (a set of web sites) from one another

  41. OMash: Object Mashup • A new browser security model • Use Object-Oriented model (e.g. Java object model) • Treat each Web page as an object • Encapsulate all scripts and data • Objects declare public interface • Objects communicate only via public interface

  42. Object Abstractions public class FooObject { public void publicMethod() { } private intprivateData; } <html> <script> function getPublicInterface() { function Interface() { this.publicMethod = function () {…} } return new Interface(); } varprivateData; </script> </html> Java (analogy) Web page object

  43. Page Objects • A page consists of • DOM tree • Scripts • Credentials (HTTP auth, cookies) • A page object can be contained in a • Window • Tab • Frame • Iframe

  44. Public and Private Members • Public interface • Each object declares getPublicInterface() • Returns a closure of all public methods and data • Private data • DOM • Scripts • Credentials

  45. Usage Example <html> function getPublicInterface() { function Interface() { this.setCenter = function (lat,long) { … } } return new Interface(); } </html> <iframesrc="map.html"> ... var map = win.getPublicInterface(); ... map.setCenter(lat, long); } integrator.html map.html map.html integrator.html

  46. Trust Relationships • Can model trust relationships needed for mashups (as identified by MashupOS) • Isolated • Open • Access-Controlled • Unauthorized

  47. Isolated function getPublicInterface() { function Interface() { } return new Interface(); } No access between provider and integrator

  48. Open function getPublicInterface() { function Interface() { this.getDocument = function () { return document; } } return new Interface(); } Full access between provider and integrator

More Related