Tech Ads
Back to Article List
Originally published May 2008 [ Publisher Link ]
Cross-site AJAX (XMLHttpRequest) : Boon or Pandora's Box
Browsers have established themselves as the IT community's ubiquitous client, even though some still consider their operation feeble for displaying large amounts of data. For better or worse, most applications now a days target the Web -- and with it browsers -- as a primary delivery medium. On a related front, software as a service has also come of age as a preferred design approach. So it is that when a technique influencing both world's emerges, it always serves for some interesting discussion on its potential implications, in this case what I am referring to is the use of Cross-Site AJAX or XMLHttpRequest.
XMLHttpRequest is the foundation for Ajax (Asynchronous JavaScript and XML), a mechanism by which browsers can perform out-of-band calls to services on the Web. Once an initial document is delivered to a browser, if its designers have equipped it with XMLHttpRequest functionality, end users can experience continuous content updates without seeing full document reloads. It's a responsive effect and one that has given birth to a wealth of applications like Maps and Calendars that were once considered impractical for the Web, but until recently, there was a limitation to using XMLHttpRequest: it could only be used for calling services on the same domain of the originating document.
Currently, the only way in which a browser can access services via XMLHttpRequest outside the domain on its main interface is via a proxy. In other words, any application requiring outside services must first obtain them directly from a serverside application and later funnel them to browsers as though the service originated on the main domain.
Enter Cross-Site XMLHttpRequest, an initiative granting browsers more flexibility in terms of the location a service can reside in. Currently launched as a W3C working draft named Access Control for Cross-Site Requests , this specification is putting forth two access mechanisms that were once not possible between browsers and the services used to fulfill Ajax requests.
The first mechanism consists of adding an HTTP Header named Acess-Control to a page response, allowing a browser to discern on what other sites it can perform an XMLHttpRequest. For example, say your application made use of a service on cnn.com and you wanted an end-user's browser to perform the service call directly to the site. Under normal circumstances browsers won't allow this, but in browsers supporting cross-site XMLHttpRequest, if your application added the HTTP Header Access-Control: allow <cnn.com>, then this operation would be possible.
It should also be mentioned that the syntax for Access-Control can contain multiple domains as well as rules for associating patterns in a domain. For example Access-Control: allow <*.acmesoft.org> exclude <*.shareware.acmesoft.org> would allow a browser to make an XMLHttpRequest to the main site acmesoft.org, but not to its shareware.acmesoft.org sub-domain.
A second mechanism for Cross-Site XMLHttpRequest consists of using a similar syntax to the first method, but based on the use of XML documents. In this case, the supported scenario would consist of delivering an initial XML document to a browser containing a pre-processing instruction: those beneath a document's root tag <?xml version="1.0"?>, like the following <?access-control allow="cnn.com" exclude="videos.cnn.com"?>. This in turn would also allow a browser to determine on what other sites' out-of-band calls are permitted.
Important lessons in these new approaches can be learned from technologies like Flash, which have had this avenue open for years. By being an independent environment embedded in a browser, Flash players and their applications have long had the capability to make remote service requests in what is practically an open fashion, but this hasn't stopped its makers from constantly tweaking security policies in Flash's handling of cross-site data loading .
The issue here is that the same features easing access to services on different domains also lend themselves to serious exploitation. Suppose that instead of calling a cross-domain service to update an interface, a cross-domain service is used to execute some type of rogue instruction or send information to an unknown source. In these cases you are exposing users to one of the many variations of cross-site scripting (XSS).
XSS is a serious -- albeit often obscure -- issue that afflicts browser users when they inadvertently execute instructions from a different domain than the one they are visiting. It is by no means new or exclusive to Cross-Site XMLHttpRequest, and is in fact on the security checklist of most mid-size organizations developing and allowing access to Web applications. XSS in itself posses a myriad of variations, so needless to say we can't elaborate on all its particularities, though you can find a few testing resources on the Web like this XSS (cross-site scripting) Cheat Sheet.
Without a doubt Cross-Site XMLHttpRequest can potentially ease the way services are combined to make up application inside a browser -- a technique often referred to as Mashup -- but in an online world already fraught with phishing scams and spyware, perhaps it should be prudent to save end user's from one more potential pitfall in their daily navigation routines. In the end, it will be vendors from both browser and serverside platforms that will have the last say in supporting Cross-Site XMLHttpRequest, though it should be wise to point out that the box for Cross-Site XMLHttpRequest started off with no key for a reason.