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

Fri Sep 28 16:18:50 PDT 2007

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?

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.
- 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. 
- Are we making the hub too complex by supporting such communication 
patterns using fragment communication?

Sumeer

"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>
cc

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

My comment in blue...  your second question is worth everyone pitching in 
some thoughts.

----- Original Message ----- 
From: Sumeer Bhola 
To: OpenAjax Alliance Security Task Force 
Cc: interop at openajax.org ; OpenAjax Alliance Security Task Force ; 
security-bounces at openajax.org 
Sent: Friday, September 28, 2007 2:24 PM
Subject: Re: [OpenAjaxSecurity] [OpenAjaxInterop] Cross-Frame Messaging 
(was SMash questions and issues)

interesting discussion. A couple of questions/comments: 

- I don't quite understand the performance implications of full-duplex 
versus two one-way channels. Since the browser modification proposals are 
for asynchronous messaging, and that is also what we can implement using 
fragments, it seems natural to require that the lower-level API support 
asynchronous messaging in both directions. 

I agree with the last statement.  The lower-level API ought to be 
asynchronous messaging.  Both the outer and the inner frame should be able 
to send a string message.  Asychronously, the outer side receives a 
registered callback with the string value. 

If everyone agrees above this point, the full-duplex vs.two channel issue 
is a less significant point.  It is just a question of how one would 
implement streaming over reliable asynchronous transport -- whether it is 
better to have two queues or a loop, etc.

- One issue with the channel/pipe abstraction offered by the lower-level 
API is privacy. With SMash, the main mashup application can listen on any 
channel, so it is not possible to implement private point-to-point 
channels between two arbitrary frames in the mashup. If the HTML 5 
proposal is implemented by browsers, this would be possible. 
It seems that SMash has an A1-B-A2 frame hierarchy for each "widget". When 
the host (A1) sends fragment to the widget, it waits for the widget frame 
(B) to sends an acknowledgment via sending a fragment to A2.   Correct me 
if I misunderstood.

But this model might be insufficient when we get into the realm of 
composite widgets.  For example, in a multi-frame webtop, you can have 
compound document widgets like spreadsheets, which contain floating frames 
of chart/drawing widgets.  The webtop, the spreadsheet, and the charts 
might come from different domains.  The question, then, is do we allow the 
chart to communicate with the webtop directly, not letting the spreadsheet 
to see the message flying in between?  For security reason, it might be 
desirable to allow that.  More importantly, given that passing data across 
domains take so long, it is a good idea.

We can let a deeply nested chart talk to the webtop by flipping the ABA 
hierarchy.  That is, we have the (chart) widget frame contains a frame of 
the toplevel (webtop) domain which contains a frame of the widget's 
domain. The first time the chart sends a message to the webtop, the webtop 
also tracks a pointer to the frame contained by the chart.  So 
subsequently, either side can send message to another.

- Regarding standardizing the protocol itself, for example, the exact 
fragment formats that SMash and XDDE use, it might be useful. On the other 
hand, as these are hopefully temporary hacks till we get browser support, 
it may not be worth too much effort. At minimum, we should document the 
protocol names, so that different entities can communicate with each other 
if they use the same protocol name. For instance, the SMash protocol could 
be used by the hub, if the scheme in the hostname used in the 
OpenAjax.hub.connect call referred to SMash. 

Well, given that the low-level is a temporary measure, we might as well 
standardize it.  It is not like people are going to compete for better 
implementations, anyway.

Sumeer 

"Gideon Lee" <glee at openspot.com> 
Sent by: security-bounces at openajax.org 
09/28/2007 10:48 AM 

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> 
cc

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

My thoughts in blue. 
----- Original Message ----- 
From: Howard Weingram 
To: OpenAjax Alliance Security Task Force ; interop at openajax.org 
Sent: Friday, September 28, 2007 4:20 AM 
Subject: Re: [OpenAjaxInterop] Cross-Frame Messaging (was 
[OpenAjaxSecurity]SMash questions and issues) 

A. (Two layers...) I agree that there should be two API layers. But when I 
think about OAH pub-sub in particular, I wonder if it might impose a 
performance penalty if the lower-level API is generalized to be a 
"TCP-like" full-duplex binary data tunneling model.  It seems to me that 
an "email-like" string-based, one-way, and acknolwedged delivery will 
already be sufficient.  We will need two such pipes to do PUB and SUB. But 
going from outer-frame to inner-frame requires a different implementation 
from the vice-versa in any case. 

Now, I am actually not advocating either string-based or one-way only 
model.  (See response to C below). I'm just saying that if every character 
counts, there is indeed a performance difference. 

B. Different upper level protocol implementations could 
in fact be layered over the same lower level, and 
different lower level protocols could implement the 
same lower level API. We should consider standardizing 
the data stream protocol API as well as the higher level. 

I agree. 

C. In cases where data is highly redundant and large messages 
are frequently sent, a data stream layer implemnentation might 
include data compression. The cost of computation might be 
much less than the cost associated with delivering fragmented data. 
Note: I am NOT suggesting that we provide a reference implementation 
that does this. It is simply a possibility that some implemneters might 
choose for their own reasons. 

Interesting.  Shouldn't compression be a feature of the OAH pub-sub 
implementations instead?  The pub-sub implementation has the whole 
JavaScript object/JSON structure to look at, so it could do many more 
clever things.  Indeed, in addition to intra-message compression, it can 
do inter-message compression, like building a string table dynamically. 

At the lower level API, there really not much compression worth doing. And 
we cannot forget that in the long term, the lower-level API is really 
meant as a lobbying effort for to the browser vendor anyway.  The browser 
itself can use native functionality to implement the lower level API. 

But OAH-level compression has other significant uses in its own right -- 
server-side OAH in particular. 

For instance, in a mashup, the host and the widgets should by default use 
URL-encoded JSON as you suggest to negotiate the best compression.  But 
beyond the first conversation, clever OAH implementations can use more 
application-optimized representations to talk to each other. 

There is clearly an opportunity for commercial competition of high-level 
OAH implementations and performance/compression could be a differentiation 
factor.  In contrast, nobody can compete with the browser when it comes to 
the low leverl API. 

D. Messages being sent between frames need to be URL-encoded 
JSON. 

Well, I agree that URL-encoded JSON is probably the best choice for the 
initial exchange for representation negotiation.  But I do believe that we 
should introduce the concept for representation negotiation as part of the 
OAH 1.1 standard. 

I am also wondering if there should be at least a place-holder for 
identity negotiation.  It may be too much for us to take on for 1.1 time 
frame.  But we should design the high-level protocol in such a way that 
identity negotiation can take place. 

In particular, it seems that there may be some reason for us to talk to 
folks at MIT Kerberos Consortium.  Single sign-on and secure mash-up are 
really hand and glove.  One is really made for the other.   

E. Gideon, what were your performance numbers for XDDE? Order of 
magnitude, I mean? 

For each fragment to be sent and acknowledged, XDDE needs two iframe 
location change.  (Like SMash A.com contains 2 B.com contains A.com).  On 
most browsers, it seems that we can get at most 10 location change per 
second. 

So I say the best we can expect is 50K going one-way. 

F. (your #3) That kind of clicking is a royal pain. 

Yes, 20Hz... ugh.   

G. Development of applications for a sandboxed mashup still requires 
developers to be quite careful. Even if the mashup itself successfully 
prevents iframe X from accessing the contents of iframe Y won't do 
any good if iframe Y is vulnerable to CSRF attacks by X. 

Right. 

Best Regards, 
Howard Weingram 

From: security-bounces at openajax.org [mailto:security-bounces at openajax.org] 
On Behalf Of Gideon Lee
Sent: Thursday, September 27, 2007 4:02 PM
To: OpenAjax Alliance Security Task Force; interop at openajax.org
Subject: [OpenAjaxSecurity] SMash questions and issues

We have something overlapping SMash at the SameDesk project and we call it 
XDDE (Cross Domain Data Exchange).  I have a small demo at: 
http://www.samedesk.com:23460/~0.0.0/webhost/com.openspot.webhost.OResource/com/xdde/demo3/system.html 

I haven't looked at the SMash code closely.  But as I listened to the 
SMash presentation, here are some questions/issues that we may need to 
sort through as we work towards Hub 1.1: 

1. What is SMash using to have the outer frame signal an inner frame to 
check window.location changes? 
XDDE has the parent frame resize the child frame, alternatiing between +1 
and -1, for each subsequent "fragment".  The child frame has an onresize 
event handler for the document.body. 

2. Does the SMash protocol allows arbitrarily long message and allow 
either side to initiatiate the conversation? In XDDE, that's what we do to 
allow that... 
(a) We always break up a long message into fragments.  And in delivery, 
when one side sends a fragment to the other side, it always waits for an 
ACK(nowledgement) fragment from the other side before sending the next 
fragment. 
(b) In a Parent-Child relationship, we want to allow either party to 
initiate a request-reply conversation.  So to make the +1/-1 trick work, 
we actually have 4-layer deep iframe enclosure A-B-A-B instead of the 
A-B-A pattern in SMash. 
(c) A long message begins with a length and an encoding description of the 
data fragment, followed by zero or more data fragments, followed by an end 
of message checksum fragment.  The reason we have encoding description is 
that different data can benefit from different encoding strategy. 
So in a way, the conversation pattern is sort of like HTTP over TCP rather 
than an bi-directional UDP.   

3. Does SMash cause annoying click sounds in IE 7 when long message with 
many #fragmet are sent?  For a short message, a click-click may not be 
that annoying.  But if it is a long message with many fragments, XDDE is 
very annoying because it sounds like old typewriters gone mad. 
BTW, since a fragment can contain at most around 4K characters, it doesn't 
really take a very long message before the click-clack-click-clack becomes 
annoying. 

4. Are there any performance benchmark on SMash yet?  Even with the iframe 
resize trick (which helps the inner frame to respond almost immediately 
without installing a window timeout), we found that XDDE is not exactly 
fast enough for the type of transfer we were trying to do. 

How we optimize the protocol depends a lot on the higher level model. When 
we did XDDE, it wasn't built around single-directional PUB-SUB, but more a 
request-reply pattern.   

5. So given OpenAjax Hub 1.0 currently allows JavaScript objects to be 
passed, I'd assume that we support try to achieve that with SMash-based 
cross-domain-data-exchange too.  How do we plan to encode a JavaScript 
object so that it can go across frames?  Do we encode it in JSON over UTF8 
over Base64? 

These are my top five issues.  I'm sure I can come up with more when we go 
down to the detail.  Overall, I like the SMash idea because it is secure. 
But I think performance and user experience should not be totally hand 
waved either.  Otherwise, people will just keep doing unsafe JSON. 

Gideon 

_______________________________________________
interop mailing list
interop at openajax.org
http://openajax.org/mailman/listinfo/interop
_______________________________________________
security mailing list
security at openajax.org
http://openajax.org/mailman/listinfo/security

_______________________________________________
security mailing list
security at openajax.org
http://openajax.org/mailman/listinfo/security
_______________________________________________
security mailing list
security at openajax.org
http://openajax.org/mailman/listinfo/security

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20070928/3f8322c5/attachment-0001.html 