Friday, September 22nd, 2006

Intra-iframe Message Passing

Category: Ajax

>Dare Obasanjo pointed to Julien Couvreur’s blog post that discusses a Cross-document messaging hack that both Dojo and Windows Live platform came out with:

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:

Posted by Dion Almaer at 12:54 pm
8 Comments

+++--
3.9 rating from 32 votes

8 Comments »

Comments feed TrackBack URI

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…

Comment by Fnustle — September 22, 2006

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?

Comment by Julien Couvreur — September 22, 2006

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.

Comment by Ahmed Kamel — September 22, 2006

Intra-iframe Message Passing

nice

Trackback by srabbit23 — September 22, 2006

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/

Comment by Joseph Smarr — September 22, 2006

@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.

Comment by henrah — September 23, 2006

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.

Comment by optimus paul — September 27, 2006

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.

Comment by Julien Couvreur — October 3, 2006

Leave a comment

You must be logged in to post a comment.