Friday, September 22nd, 2006
Intra-iframe Message Passing
Category: Ajax
The Dojo and Windows Live Platform teams have both recently released DHTML hacks that allow two iframes in different domains to communicate, bypassing the notorious same-domain policy implemented in browsers. I’m surprised by the relative lack of response in the AJAX blogosphere, as this opens lots of possibilities for mashups.
The basics:
The hack relies on dynamically created iframes, using the fragment identifier to leak/communicate information to the other domain and timers to check for iframe changes.
For example, if you have page A containing an iframe B in a different domain, then B can create a new iframe and load it with a url in the same domain as A.
The url that is loaded doesn’t generate a request to the server if it is properly cached and only the fragment identifier is used to pass changing information. Page A can now get the DOM handle on the new iframe and successfully retrieve the information transmitted in the url by B.
Julien finishes up with a question to the community: “Now, the question is what cool applications will you build with this new cross-domain capability?”
Related Content:
- How do I use message-driven bean (MDB)?, part 1
4.1 rating from 27 votes
Neat, but I wouldn’t rely on a security hole staying around even if it is one that would be highly improbable to exploit, given the hypervigilant attitude MS has had towards security…
Fnustle, I don’t think that this can be “fixed”. There is no hole per-se. Which part would you want to fix? The ability to create iframes that load any url? The ability to enumerate all iframes in a document?
I agree that this doesn’t seem to be a security hole; because it requires both frames (parent and iframe) to work together, and hence neither A or B can exploit each other.
However, this can become an exploit, if E (for evil) comes along and decides to spoof B’s dynamic iframe creation; passing bad information to A.
Somehow a security mechanism (identification) must be established between A and B.
Intra-iframe Message Passing
nice
For those interested in more info and more options for cross-site scripting technicques and their challenges, you might enjoy the talk I gave this year at OSCON on the subject (including the infamous “JavaScript Wormhole”).
Slides:http://www.plaxo.com/css/api/Joseph-Smarr-Plaxo-OSCON-2006.ppt
Summary: http://www.sitepoint.com/blogs/2006/07/28/oscon-2006-cross-site-ajax/
@Fnustle:
> given the hypervigilant attitude MS has had towards security…
Since the Windows Live team is actually exporing this technique, it’s reasonable to assume that Microsoft are treating this as a security solution rather than a flaw.
I’ve always found it easier and perhaps better do do my mash-ups on the server, then there are no xss concerns. I’ve never really understood the fascination with attempting to do xss in ajax.
I do think this is good news, now we can get the problem fixed.
Optimus Paul,
Privacy reasons would prevent you from implementing the Windows Live Contact Gadget by doing the mashup on the server.
Another reason for doing client-side cross-domain communication is to avoid un-necessary proxying traffic to your server. Agreed there are times where this traffic is necessary, but in many occasions it is not.