1 / 27

Subspace: Secure Cross-Domain Communication for Web Mashups

Subspace: Secure Cross-Domain Communication for Web Mashups. In Proceedings of the 16th International World Wide Web Conference. (WWW) , 2007 Collin Jackson, Stanford University Helen J. Wang, Microsoft Research. Outline. Introduction Current Practice Single Web Service

mandar
Télécharger la présentation

Subspace: Secure Cross-Domain Communication for Web Mashups

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. Subspace: Secure Cross-Domain Communication for Web Mashups In Proceedings of the 16th International World Wide Web Conference. (WWW), 2007 Collin Jackson, Stanford University Helen J. Wang, Microsoft Research

  2. Outline • Introduction • Current Practice • Single Web Service • Multiple Web Services • Evaluation • Conclusion and Comments 2

  3. Introduction • Mashup • A website or web application that seamlessly combines content from more than one source into an integrated experience. • Gadget aggregators aggregate third-party JavaScript code, the gadgets, into one page to provide a desirable, single-stop information presentation to their users. • Google Personalized Homepage, Microsoft Windows Live 3

  4. Introduction • Browsers are poorly designed to pass data between domains, often forcing web developers to abandon security in the name of functionality. • Subspace • A cross-domain communicationmechanism that allows efficient communication across domains without sacrificing security • A small JavaScript library, and works across all major browsers

  5. Introduction • How to obtain third-party data • <script> tags: one site gets complete control. • Allows observing or hijackinguser’s session • Browser plugins: inconvenient • Gadget aggregators typically are presented with two security choices: • Inline gadgets: allow the gadget full access to the surrounding page • Sandboxed cross-domain frames: cannot engage in client-side communication with the parent frame

  6. Current Practice • How mashups currently communicate across domains: • Same-origin policies • Proxies • Cross-domain <script> tags • Browser plugins • Fragment identifier messaging 6

  7. JavaScript Same-origin policy • Inline frames (IFRAMEs) • Can be used to download rich HTML documents from outside sources • If the content comes from a different domain, the browser will not allow the JavaScript in the containing page to read or manipulate the document inside the frame, and vice versa.

  8. JavaScript Same-origin policy • XMLHttpRequest • Can be used to download arbitrary XML documents without reloading the page • Cannot be used to download files that are not from the same domain as the page making the request • Protects the secrecy of HTML documents that the user has access to • Protects the integrity of a page against unauthorized modification by other pages

  9. Proxies • The website hosting the mashup can host a URL which relays data between the client and the source of the data. • Makes the data appear to the client to be “same-origin” data, so the browser allows the data to be read back. • Disadvantages • Adds latency • Increases bandwidth costs • Provide another layer for hackers to hide behind for DoS or exploiting input validation vulnerabilities on the server hosting the data source

  10. ServerofOriginSite.com Client / Browser Loaded from ServerofOriginSite.com XMLHttpRequest MashupSite.com XMLHttpRequest HTTP GET, HTTP POST

  11. Cross-domain <script> tags <script type=“text/javascript” src=http://shoeboxfullofapes.org/formprocessor.php>” • Scripts can be loaded from other domains and executed with the privileges of the page that include them. • Disadvantages • A script can only be accessed by executing it. • The page including the script has no way of performing input validation to ensure that the script being retrieved is not misusing its access to the parent page. • The site hosting the script could change the content of the script at any time, and could even serve different content to different users.

  12. Browser plugins • Can provide many of the cross-domain network communication capabilities that are needed by mashups • Macromedia’s Flash browser plugin • Disadvantages • Some users choose not to install them for security, privacy, or compatibility reasons

  13. Fragment identifier messaging • Fragment identifiers • The hash part of an URL • a URI pointing to an anchor named section_2: • The containing page sets (but not read) the URL fragment identifier of an embedded IFRAME, and the IFRAME must poll to detect changes in the value of its location.hash property. • Disadvantages • Require careful synchronization between the communicating pages • Can be easily disrupted if the user presses the browser’s back button http://somesite.com/html/top.html#section_2

  14. Single Web Service top.www.mashup.com www.webservice.com ？ • Introduce a “throwaway” subdomain(e.g. webservice.mashup.com) that is used only toretrieve information from that web service • Used only by IFRAMEs. These frames are structured such thatdata can be safely downloaded from www.webservice.comusing a <script> tag • None of the browser state associated with top.www.mashup.com (eg. the user’s authentication cookie, or the contents of a page) are ever accessible to www.webservice.com The mashup site The untrusted web service 15

  15. Cross-subdomain Cummunication • If two domains that want to communicate share a common suffix, they can use the JavaScript document.domain property to give each other full access to one another. • Defaults to the host name of the server that the document was retrieved from • Can be truncated to a suffix (and only a suffix) of this name. Must occur on dot-aligned boundaries • Pages on a.example.com and b.example.com can change the value of document.domain to example.com, allowing them to pass JavaScript data and code between each other at runtime. • Once a page has shortened its domain using this mechanism, it is no longer permitted to access other frames that do not match its new domain. • It cannot set document.domain back to its original value

  16. Single Web Service - Setup Phase Perform a setup protocol that gives pages in both domains access to the same Subspace JavaScript object. • Create mediator frame: the top frame(top.www.mashup.com) and the mediator frame (a hidden iframe pointing to a tiny page on www.mashup.com) set their document.domain variable to www.mashup.com • Create untrusted frame • Pass JavaScript communication object: The mediator frame and the untrusted frame change their document.domain to mashup.com. Can use the same Subspace object to pass arbitrary JavaScript data. 17

  17. Performed only once and does not need to be restarted when further data requests are required • The top frame and the mediator frame cannot directly communicate, because their domains don’t match. • the top frame is protected • The mediator frame cannot issue XMLHttpRequests to top.www.mashup.com • the cookie belonging to top.www.mashup.com is not accessible to the code hosted on webservice.mashup.com

  18. Multiple Web Services • If the mashup wants to interact with more than one web service or gadget, it not only needs to protect the security of its own domain, it also needs to keep these web services fromcompromising each other. • The untrusted frame for every web service lives in the mashup.com domain • An attacker’s untrusted frame might be able to interfere with the untrusted frame of another web service • Whether or not this issue is a problem is depends on the frame restrictions imposed by the browser 19

  19. Frame Hierarchy • upperFrame is top.frames[0] • navigateFrame is top.frames[1] • listFrame is upperFrame.frames[0] or top.frames[0].frames[0] • contentFrame is upperFrame.frames[1] or top.frames[0].frames[1]

  20. Multiple Web Services - Restrictive frame access • The browser restricts access to cross-domain frames when navigating the frame hierarchy • Opera and some configurations of IE6 • Create a new nested frame structure for each web service or gadget that needs to be included.

  21. Multiple Web Services - Permissive frame access • Any frame anywhere on the page can be reached by any other frame, and if those frames are in the same domain, they can each access each other and intercept each other’s communications • Firefox, Safari, IE7, and some configurations of IE6 • Use a new throwaway domain for each web service that the mashup needs to interact with • keep these frames from interfering with each other webservice1.mashup.com ？ top.www.mashup.com The untrusted web service ？ webservice2.mashup.com The mashup site The untrusted web service

  22. Create mediator frame: the browser is at top.www.mashup.com. Create an IFRAME pointing to a page on www.mashup.com. Retrieve JavaScript object and change domain. Create untrusted frame Create access frame: obtain a “container” JavaScript object from the untrusted frame and then change domain to mashup.com Pass JavaScript communication object: the access frame can obtain the Subspace object from the mediator frame (due to permissive frame access policy and the same domain). Put the object into the container it shares with the untrusted frame. Cleanup: the untrusted frame disposes of the access frame. It has the Subspace object to communicate with the top frame. Repeat for every gadget: then the mediator frame can be disposed. Load untrusted content: all the gadgets have a Subspace communication channel to the top frame, but none of them have access to each other. Mediator Frame: mashup.com webservice1.mashup.com ？ top.www.mashup.com The untrusted web service ？ webservice2.mashup.com The mashup site The untrusted web service webservice1.mashup.com

  23. Mashup Measurements Shows a list of the 20 most recent kitten photos from the Flickr phto sharing site. Evaluation • Proxy: connects to the Flickr web service and relays data to the mashup. Use XMLHttpRequest. • Unsafe: downloads the data directly from Flickr using a cross-domain <script> tag. • Subspace: also use <script> tag to make network request. • Subspace took longer to set up (load hidden IFRAMEs), but its network requests were faster than the proxy approach 24

  24. Evaluation • Gadget aggregator Measurements • Allows the user to customize the font color of all his or her gadgets. • Sandboxed: use a third-party iframe approach that reloaded the gadget whenever the user’s desired font color changed. • Unsafe: include the gadget’s source code inline with the page. Use JavaScript to pass the desired font color to the gadget region of the page. • Subspace • Initial page load: sandboxed and unsafe approaches were faster (fewer frames were required) • Respond to a font color change request: the sandboxed approach required the user to wait for the page to load 25

  25. Presented Subspace, a cross-domain communication primitive that allows efficient communication across domains while still sandboxing untrusted code. Uses existing browser features as building blocks and is therefore is highly practical. Prototype implementation of Subspace is compatible with all major browsers. Conclusion 26

  26. Looks brilliant to me for scenarios where the Web application developer is looking to achieve secure mashups because it works with today's browsers without requiring any plugins The strategy requires that the server have a stash of subdomains lying around. Comments 27

More Related