When two web applications are communicating through a user's browser, for instance to provide the user a mashup, the applications do not have a standard and secure method of authenticating each other and establishing a secure channel. In addition to the risk of MITMs (man-in-the-middle) between the user and one of the web applications, there is the additional, potentially bigger, risk of a malicious user. We motivate this problem with a very simple thought exercise. Imagine that there is an online movie site that delivers its service using a web application coded in AJAX or any other Rich Internet Application (RIA) platform. Now there is another online business which provides rare classic clips of movies. This business does not directly sell content to users, but has business relationships with online movie sites through which it provides content to end users.
So if Alice is logged into her online movie site, she might perhaps click on a link which allows her to view a classic movie clip which is being served up directly by the classic clips service. The technology behind the scenes in our example is cross-domain XHR which works as follows. When Alice clicks on the classic clips link, her browser sends a request to the classic clips application. The application examines the ORIGIN header, and it appears that Alice is coming to it from one of its authorized partners, then it will send back the name of that partner in the form of an Access Control List (ACL). The browser sees that the site Alice is coming from is present in this ACL and allows the cross domain XHR request to proceed. Now obviously by itself this scenario is not feasible as Connie a Content Thief can easily spoof the classic movie site by sending requests with any ORIGIN she wants. This mechanism is really intended to protect a legal user from malicious attacks; not protect a legal service from a malicious user.
The underlying problem is that the classic movies site has no ability to "look behind" the user's browser and securely determine where she is coming from. This is not a cross domain XHR problem. The same problem repeatedly shows up in a variety of contexts. For instance:
- In mashup canvases an enterprise might deploy (perhaps using OpenAJAX), the enterprise cannot really look through the browser to see where the user is downloading widgets from.
- The OAuth protocol does take steps to try and address this issue but requires some participants to obtain and manage lots of additional credentials, and other participants need to get in the business of vetting business identities and issuing credentials.
- Most identity federation protocols, e.g. OpenID, recognize this problem and invent checks to try and prevent various attacks.
The list goes on, and the problem is that there is no standard secure application layer protocol for allowing two web applications communicating through a browser to authenticate each other securely, and to establish a secure channel, even in the presence of MITMs and malicious users.