Cross Domain XHR

The Problem

Consider the following simple problem: Classic_Movie_Clips.com operates a service by which it provides streaming video of rare movies. Its business model is not consumer direct. Rather, it forms alliances with popular movie sites such as See_Movies_Here.com. When a user, Alice, logs onto See_Movies_Here.com and clicks on a link that is actually served by Classic_Movie_Clips.com, her browser makes a request to the latter site. How does Classic_Movie_Clips.com decide whether to grant Alice access?

Here are some options. Classic_Movie_Clips.com:

  1. Could maintain an Access Control List (ACL) of all partner sites, check the ORIGIN header in the request from Alice's browser, and if the ORIGIN header's site is present in the ACL it could return that value as an ACL to the browser. The browser will then examine if the value returned in the ACL matches the ORIGIN and allow access.
  2. Could be forced into the business of maintaining user identity and authenticating the user directly or through some federation protocol.
  3. Could implement some proprietary cryptographic handshake protocol with its partners, which ensures Alice arrives at the site with some “ticket”, requesting service.

These are all sub optimal options. The first which is roughly speaking the W3C specification for cross domain authorization, can be defeated by Connie the Content Thief who simply spoofs the ORIGIN header to one she thinks will work. (Obviously the specification assumes some other mechanism will protect the web application from a malicious user; and the mechanism is mainly to protect legitimate users from malicious web servers). The second option is even worse in that it is forcing a business that does not want to maintain user information to collect more user information from a user who may not want to reveal information to more web services. The third option can provide a technical solution but would rely on using a protocol that has not been standardized and has not stood the test of time, and will require yet another set of credentials to be managed.

The MashSSL Solution for Cross Domain XHR

While there are many ways to integrate MashSSL with cross domain XHR the method described below ensures that it works with the W3C specification without requiring any changes. We have tested our implementation with IE 8 Beta which implements the specification. The sequence is as follows:

  • The user is logged into See_Movies_Here.com and the AJAX code she has downloaded has a cross domain request to Classic_Movie_Clips.com.
  • When Classic_Movie_Clips.com gets the request for the ACL it redirects to See_Movies_Here.com with the first MashSSL Client_Hello message.
  • The rest of MashSSL then plays out between the sites using redirects, and at the end of which Classic_Movie_Clips.com knows it is dealing with See_Movies_Here.com, at which point it returns an ACL with Classic_Movie_Clips.com.
  • The browser will allow the cross domain request to flow.

We have shown how MashSSL can work with the existing W3C standard by using the ACL and browser based enforcement mechanism described in that proposal, without requiring any changes to that specification. Note however, that it is really Classic_Movies_Clips.com that is enforcing its own policy, and it does not trust the browser at all. Perhaps a future revision of the W3C specification might contemplate not requiring the fetching of the ACL when MashSSL is run between the two web services.