Subspace: Secure Cross-Domain Communication for Web Mashups

1. Subspace: Secure Cross-Domain Communication for Web Mashups Collin Jackson Stanford University Helen J. Wang Microsoft Research ACM WWW, May, 2007 Presenter: Yi-ning Chen

2. Outline • Introduction • Current practice • Subspace • Building blocks of Subspace • Single web service • Multiple web service • Evaluation • Discussion • Related work • Conclusion and Comments

3. Introduction (1/3) • A mashup is a Web page or application that uses and combines data, presentation or functionality from two or more sources to create new services. • Gadget aggregators, such as iGoogle, aggregate third-party JavaScript code, the gadget, into one page to provide a desirable, single-stop information presentation to their users.

4. Introduction (2/3) • Mashup must circumvent the traditional same-origin web security model to obtain third-party data, facing a choice between security and functionality. • Gadget aggregators typically are presented with only two security choices • Run gadgets inline in the same domain as the gadget aggregator, so gadgets can access the information of gadget aggregator. • Sandbox them in frames with different domains to ensure that they cannot read or write the aggregator page

5. Introduction (3/3) • In this paper, authors present Subspace, a communication primitive that enables cross-domain network request and client-side communication, while protecting the aggregator from malicious web services or gadgets. • It’s practical as it combines existing browser feature and requires no client-side changes.

6. Current practice (1/5) • Same-origin policies (SOP) • Definition: • “Only the site (pages with same origin) that stores some information in the browser may read or modify that information.” • Two pages have same origin (domain) if the protocol, port, and host are the same. • SOP is not interpreted literally but rather applied loosely as a collection of same-origin policies on individual browser feature, such as cookies. • Disadvantage: • SOP restricts cross-domain communication

7. Current practice (2/5) • Proxies • Make the data appear to the client to be ”same-origin” data. • Disadvantages: • high latency of connecting to proxy server • Proxy server may become the target of DDoS attack Web service Web service Proxy Mashup Bandwidth bottleneck Browser

8. Current practice (3/5) • Cross-domain <script> tags • The origin of a script file (.js) is defined as the domain which executes it, not the domain which hosts it. So the script can access all resources of the page which executes it. • Disadvantages: • There is no input validation to ensure that the script it not misusing it access to the parent page. b.com/c.js …… //Retrieve the cookie of a.com <script src=“http://b.com/c.js”/> a.com The origin of c.js here is a.com

9. Current practice (4/5) • Browser plugins • e.g. crossdomain.xml file of Macromedia’s Flash placed on the server that wishes to open up some or all of its files to cross-domain reading. <cross-domain-policy> <allow-access-from domain=“*”/> </ cross-domain-policy> • Disadvantages: • It’s inconvenient for users who are unwilling to install new software. • Some browsers might not supported by the plugin.

10. Current practice (5/5) • Fragment identifier messaging • window.locationobject can be set (but not read) by frames of another origin. • Example: http://ajaxify.com/run/crossframe/# • Disadvantage: • Can be easily disrupted if the user presses the back button. http://ajaxify.com/run/crossframe/# if (window.location.hash=="#speedUp" && liftInterval>=60) { • liftInterval=Math.round(0.8*liftInterval); launchLift(); window.location.hash = "#"; } $("speedUp").onclick = function() { parent.window.location.hash = "speedUp"; } http://ajaxpatterns.org/crossframe/#turquoise

11. Subspace • Building blocks of Subspace • Single web service • Multiple web service

12. Building blocks of Subspace (1/4) • Cross-subdomain communication • If two domains share a common suffix (e.g. example.com), they can use JavaScript document.domainproperty to give each other full access to one another. • After setting the domain, the page is no longer permitted to access other frames that do not match its new domain.And it cannot set document.domain back to its original value. • Changing document.domain to top level domain names (e.g. “com”) is not allowed. document.domain=“abc.com”; abc.com a.abc.com b.abc.com document.domain =“abc.com”; abc.com

13. Building blocks of Subspace (2/4) • Cross-domain code authorization • A closure is a function that refers to free variables that were in scope when it was created, but are not in scope when it is called. child.h(); example.com When parent page call h() in the child page, the return value will be the height of child page. function h() { return document.body.clientHeight; } example.com

14. Building blocks of Subspace (3/4) • Two authorization policies when a web page pass a closure to its frame • Dynamic authorization (adopted in Opera and Safari) • The closure inherits the security privileges of the page that is calling it. • Static authorization (adopted in IE and Firefox) • The closure inherits the security permissions of the page where closure was created.

15. Building blocks of Subspace (4/4) • Cross-domain frame access • Permissive (Firefox, Safari) • Allow the frame structure of the page to be navigated so that the cross-domain frame can find another frame in the same domain. • Restrictive (Opera) • Does not allow access to the frames object of a cross-domain frame, preventing the frame structure of the page from being navigated. • Configurable (IE~IE6) • Provides a setting called “Navigate sub-frames across different domains”, and is enabled by default. • Permissive, but restrict location (IE7) • Like IE 6, but always restrict some types of fragment identifier messaging.

16. Single web service JavaScript communication object Pass object Callback or polling • Goal: • Passing data from untrusted web service to the mashup site. • Protecting the property of mashup site from accessing by untrusted web service. Create mediator frame Create untrusted frame Pass communication object Mediator and untrusted frame change their document.domain Pass communication object Get untrusted frame’s data by callback or polling Top Frame: www.mashup.com Mediator Frame: mashup.com Mediator Frame: www.mashup.com Untrusted Frame: mashup.com Untrusted Frame: webservice.mashup.com

17. Multiple web services (1/4) JavaScript communication object Pass object Callback or polling • Goal: • protecting top frame and keep the web services from compromising each other. • Restrictive frame access – Top-Mediator-Untrusted (TMU) • Like single web service because the browser restricts access to cross-domain frames when navigating the frame hierarchy. Top Frame: www.mashup.com Mediator Frame: www.mashup.com Mediator Frame: www.mashup.com Mediator Frame: mashup.com Mediator Frame: mashup.com Untrusted Frame: webservice1.mashup.com Untrusted Frame: webservice2.mashup.com Untrusted Frame: mashup.com Untrusted Frame: mashup.com

18. Multiple web services (2/4) JavaScript communication object Pass object Callback or polling Shared container • Permissiveframe access– Top-Untrusted-Access (TUA) Mediator Frame: mashup.com Mediator Frame: www.mashup.com Top Frame: www.mashup.com Access Frame: mashup.com Access Frame: mashup.com Access Frame: webservice1.mashup.com Access Frame: webservice2.mashup.com Untrusted Frame: webservice1.mashup.com Untrusted Frame: webservice2.mashup.com

19. Multiple web service (3/4)

20. Multiple web service (4/4) • Setup integrity • Problem: • The attack may open a popup window through a web service to retain control over the browser session, then restarts the mashup site. During the second setup process, the popup could try to find the mediator and access frames and malicious modify them to corrupt Subspace channel. • Solving approach: • A mashup should ensure that the domain used to communicate is different from one page load to the next. • Use public key cryptography to protect communication

21. Evaluation • Mashup measurements • Unsafe: using cross-domain <script> tag • Browser: IE7 • Gadget aggregator measurements • Browser: IE7

22. Discussion • Subdomain problem can be solve by running: document.domain = document.domain; • The domain will be opened to all its subdomain. • limitation of Subspace: • Frames can launch a DDoS attack on the browser • Untrusted data source or gadget would pop up a new window asking the user for their authentication credentials. • Input validation • Cross-site scripting

23. Related work • XML access-control instruction <?access-control allow=“*mashup.com”?> • JSONRequest • JavaScript Object Notation (JSON) is a data presentation that is designed to parse as valid JavaScript. It’s not safe because the data may contain malicious active code. • JSONRequest browser object parses the JSON data without interpreting it as code, and capable of performing cross-domain data requests. • BrowserShield • Using sandbox in browser to detect and filter malicious cross-domain behavior. • Cross-document message • Implementing in Opera, allowing a frame to send string message to other frames from different domains. document.addEvenetListner(‘message’, handler, false)

24. Conclusion and Comments • Because of SOP, cross-domain communication is a full-or-no trust module. • Subspace creates mediator and access frame in a mashup to build safe cross-domain communication channel between service providers and service aggregator. • Setup phase of Subspace costs much time than other approaches and may cause setup integrity problem.