PART II
Chapter 7: Security Concerns 333
Now, this is all fine, but as you have seen, no site that content is fetched from should be
trusted to execute within your page. If the content can be evaluated at somewhat of a
distance, maybe any rogue scripts can be kept from accessing data or cookies in the page. To
accomplish this degree of indirection, a number of iframes are used that set different
document.domain values to create a chain of trust. As an example, we have a main page
running under the domain www1.ajaxref.com. We have a bridged iframe document that
also initially starts out running under www1.ajaxref.com. It then sets up a link object with
the main page and changes its domain to ajaxref.com. A requesting iframe is included and is
running under www2.ajaxref.com. It also sets its document.domain to ajaxref.com so that
the bridge domain can pass the link object from the main page to it. Then the bridge domain
has finished its work and the main page and the request iframe communicate through the
object. We illustrate the relationship here:So how does this convoluted iframe scheme help? Well, as long as the cookies are stored
in a higher domain (that is, www1.ajaxref.com), the request page, and therefore any
executing code, will not have access to them and you are protected from the scripts and
JSON data returned from the sites you are querying. This technique can be seen in action at
http://www1.ajaxref.com/ch7/externaljson.html and in Figure 7-17.
If this technique seems quite messy, we whole heartedly agree, but until browsers begin
to support cross-domain XHR requests, it is a good idea to make the effort to understand
this technique. We’ll pick up a discussion of cross-domain calls and their implications again
when Web services are discussed in Chapter 10, but for now readers are duly warned that
every call you make opens up a trust concern, so allowing same-origin breaks could be the
equivalent of opening up a proverbial Pandora’s box for Web application security.NNOT EOTE The iframe security technique to shield pages from rogue scripts is called Subspace by some
Web professionals and has been discussed at conferences like www2007 (http://www2007.org/
program/paper.php?id=801), so despite being very peculiar it is not at all esoteric.