[OpenAjaxSecurity] [OpenAjaxInterop] Cross-Frame Messaging (was SMash questions and issues)

Gideon Lee glee at openspot.com
Sat Sep 29 11:10:51 PDT 2007

My comments in normal black type.  

(*** BUT Before that***: I talked to Doug Crockford about SMash yesterday.  He thinks it'd work but it might be too slow for what Yahoo needs.  He is really looking for a secure replacement for JSON. 

Then it occured to me that instead of injection a .js to a page like JSON, we could bring in a .css and encode the data payload as style properties.  I've done a few simple proof-of-concept tests to make it work on IE and Firefox. I'll post another email after this email to explain the idea.  

For the purpose of this discussion, my point is that .css as payload approach can complement the SMash approach as a performance booster. This can greatly enhance the usefulness of SMash. ***)

Your composite widget scenario is very interesting. I think the approach you are proposing does not just enable communication between a frame and its ancestors, and could be generally used to allow direct communication between arbitrary domains, whatever their position in the frame hierarchy. And it would allow a component/frame to communicate with multiple endpoints. It resembles the XDDE A-B-A'-B' setup (A, A' are in the same domain and similarly for B, B'), in that B can also have another child C' which has a child B''. And so B can communicate with both A and C. Is my understanding correct? 

Actually, that's half of what I meant.  

Since the spreadsheet (B) and the embedded chart (C) are likely going to interact actively, allowing them communicate directly via a C-B'-C' as you understand is a good idea.  However, it is even more essential for C to talk to the webtop A directly, too.  And my point is that it could be accomplished by another iframe hierarchy in C, as in C-A"-C".

I'd limit this to two channels, child-parent and child-toplevel communication, because B' can find B easily as window.parent.parent and A" can find A easily as window.top.  Beyond these two cases, it becomes much harder for the "proxy" frame (B', A") to find home.  

General messaging between two widgets should be responsibility of the root OpenAjaxHub (OAH) at the webtop A.  It is therefore more important for a nested widget to establish a tunnel with the webtop A than even to the parent, because that way, A can always forward it to one or more widgets, including B, using publish-subscribe.  Having a direct B-C child-parent tunnel is only a performance help, not really necessary.

The approach sounds technically feasible, but we should think through some of the issues: 
- How will this be manifested in the API in a manner that is usable? Currently in SMash, the 'tunnel' URL (A') is passed from A to B, which allows us to setup A-B-A', without requiring B to have apriori knowledge. Additionally, A' knows that it can find A by referencing parent.parent. For arbitrary B to C communication, how would B know the URL for C' and how would C' find C. 

In SameDesk, when a B (spreadsheet) opens an embedded C (chart), it appends its own URL of B' to the URL of C after #.  For example, say http://www.calcsheets.com/ is the spreadsheet B and http://www.calcgraph.com/ is the chart C.  B opens the frame as http://www.calcgraph.com/#http://www.calcsheets.com/proxy.html if proxy.html is where B' is.

I'm sure there are better ways that is more robust in encoding. But the point is that the parent tells its child the URL of the proxy.  Once B-C established a tunnel, C can ask B for the proxy URL of A'.  And C can establish a connection to A'.  From that point on, OAH at A can be employed as message relay.

- Can this be secured? We pass a secret from A to B when creating B, so we can identify it when it creates A'. For arbitrary B to C communication, B would need to know something to authenticate itself to C. I can imagine a challenge-response protocol over fragments (this would work since B cannot fake its URL to C', otherwise C' would delete B by writing something to B's document.location that changes not just the fragment), but we would need to carefully analyze the security. 

You are correct in raising that issue. I know for sure that IE7 blocks script to change the location.href of another frame unless it is either a child frame or comes from the same domain. So it won't be a problem of IE7.  But it's worth looking into behavior on other browsers.

The worst case scenario is that we don't allow direct parent-child communication and always relay via OAH at the root.  Browsers allow the window.top to enforce a user prompt when its window.location is changed.

Mutual authentication between two principals (widget-widget, widget-user, widget-webtop) can be done via high level OAH-relayed message.  Personally, I'll very interested to see if what we are doing with Secure Mashup can somehow be tied to what the recently relaunched MIT Kerberos Consortium is trying to do. 

- Are we making the hub too complex by supporting such communication patterns using fragment communication? 

In light of the potential security problem you just raised, one simplification is to only support child-root communication.  That will require the parent to pass down the proxy address of A' instead of its own proxy address B'.

I really don't think fragment communication is that complicated.  Considering how useful compound document and composite widget have proven to be on the desktop, this is well worth at least a try.  Furthermore, hopefully, this is mostly a lobbying exercise for browser vendors to bring secure corss-domain/cross frame communication into the browser.

Gideon Lee

      "Gideon Lee" <glee at openspot.com> 
      Sent by: security-bounces at openajax.org 
      09/28/2007 04:02 PM Please respond to
            OpenAjax Alliance Security Task Force <security at openajax.org> 

     To "OpenAjax Alliance Security Task Force" <security at openajax.org>, <interop at openajax.org>  
            Subject Re: [OpenAjaxSecurity] [OpenAjaxInterop] Cross-Frame Messaging        (was        SMash questions and issues) 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20070929/20c6b8d5/attachment.html 

More information about the security mailing list