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

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

3. 3

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

5. 5

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

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

8. 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 8 http://integrator.com/ <iframe src=“http://provider.com/p.html”> http://integrator.com/ <script src=“http://provider.com/p.js”> X

9. Same Origin Policy a.com b.com Server Browser  

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

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

12. 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 12 Samy is my hero

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

14. 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)

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

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

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

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

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

20. Trust Relationship between Providers and Integrators i.com Content Semantics AbstractionRun- as 20 p.comi.com Internet http://i.com/ HTML XHR X X No Isolated p.com <iframe src=“http://p.com/c.html”> X

21. Trust Relationship between Providers and Integrators i.com Content Semantics AbstractionRun- as 21 p.comi.com Internet http://i.com/ Script XHR No Isolated p.com Yes Open i.com <script src=“http://p.com/c.js”>

22. Trust Relationship between Providers and Integrators i.com Content Semantics AbstractionRun- as 22 p.comi.com Internet http://i.com/ No Isolated p.com Yes Open i.com NoYes X

23. Trust Relationship between Providers and Integrators 23 p.comi.com Internet http://i.com/ 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 principal’s resources. <sandbox src=“http://p.com/c.html”>

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

25. Private Sandbox Content if tag not supported 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 25

26. Open Sandbox Content if tag not supported 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 26

27. 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 and –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 27

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

29. Sandbox for Safe Mashups with Ease 29 http://Mashup.com/index.htm // local script to Mashup.com // calling functions in a.js and b.js … X X

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

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

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

33. 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 () { …} 33

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

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

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

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

38. 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); 38 Direct access CommRequest

39. Demo 39

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

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

42. Related work Crockford’s –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 42

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

44. Object Abstractions Java (analogy)Web page object public class FooObject { public void publicMethod() { } private int privateData; } function getPublicInterface() { function Interface() { this.publicMethod = function () {…} } return new Interface(); } var privateData;

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

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

47. Usage Example map.htmlintegrator.html function getPublicInterface() { function Interface() { this.setCenter = function (lat,long) { … } return new Interface(); }... var map = win.getPublicInterface();... map.setCenter(lat, long); } map.html integrator.html

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

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

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

51. Limited access depending on caller Access-controlled function getPublicInterface() { function Interface() { this.auth = function(user,pass) { return token; } this.do = function (token,...) { check(token); } } return new Interface(); } var api = win.getPublicInterface(); token = api.auth(user, pass); api.do (token,...) ProviderIntegrator

52. Preventing CSRF a.com b.com Server Browser

53. Preventing CSRF a.com b.com Server Browser

54. Preventing CSRF a.com b.com Server Browser No cookie!

55. Browser Sessions under OMash Each cookie –belongs to a window –is shared by subsequent pages from the same domain in that window Each window has an independent session –Desirable side effect: Can log in to multiple accounts in different windows in the same browser

56. Cross-window Sessions How to track a session across windows? Cookie Inheritance –When page P1 loads P2, P2 inherits P1’s cookies –P1 and P2 now belong to the same session

57. Implementation Proof of concept as Firefox add-on –Make an exception to SOP in Mozilla’s Configurable Security Policy –Change Cookie Manager to make each cookie private to a window No changes required on the server

58. Supporting SOP without DNS If application prefers using SOP to allow inter-page communication: To implement this under OMash –Server embeds a shared secret in all pages –Pages authenticate each other using this secret

59. Supporting SOP without DNS secret = “1234”; function getPublicInterface() { function Interface() { this.foo=function (secret, … ) { check(secret); … } } return new Interface(); } secret = “1234” api = win.getPublicInterface() api.foo(secret, …) ProviderIntegrator

60. Related Work MashupOS (Wang et al, SOSP 07) SMash (Keukelaere WWW 07) Google’s Caja

61. Conclusion OMash a new browser security model –Allows flexible trust relation –Simple –Familiar, easy to understand Don’t rely on Same Origin Policy –Prevent CSRF attacks –Allows programmers to define “Same Origin” flexibly based on shared secrets

62. Future Work Robust implementation of the protection model 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 62

63. Conclusions Web content involves multiple principals Browsers remain a single principal platform The missing protection abstraction: Unauthorized content and –Enable safe mashups with ease –Combats cross-site scripting in a fundamental way CommRequest allows fine-grained access control across isolation boundaries Practical for deployment 63

64. Thank you! 64