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

Howard Weingram weingram at tibco.com
Fri Sep 28 08:56:52 PDT 2007

I, too, have implemented subspaces in conjunction with
the OAH. Subspaces is elegant and I like it a lot for a number 
of use cases. However, this approach suffers from serious 
security flaws if the mash-up application needs to be 
able to load new components dynamically. 
The Subspaces approach that would need to be implemented
in the general case relies on the assumption that a setup
phase occurs up front, before any risky content is loaded.
This approach is therefore insufficient to support dynamic
mash-ups, many types of multi-page mash-ups and the like.
Subspaces also does not inherently address "frame phishing"
and other issues. Solutions to these issues would be required
even in those cases in which Subspaces is used.
Best Regards,
Howard Weingram


	From: interop-bounces at openajax.org
[mailto:interop-bounces at openajax.org] On Behalf Of Kris Zyp
	Sent: Friday, September 28, 2007 8:42 AM
	To: Gideon Lee
	Cc: interop at openajax.org; OpenAjax Alliance Security Task Force
	Subject: Re: [OpenAjaxInterop] Cross-Frame Messaging
(was[OpenAjaxSecurity]SMash questions and issues)
	Earlier I had suggested using the subspace approach, as I have
implemented subspace and could donate my code (CrossSafe). Subspace
solves most of these problems, because real JS objects can be passed
between frames: no polling, no serialization, no fragmentation, no
encoding, no need for compression, no 20Hz clicking. Previously it
didn't sound like there was interest in this, but if there is, I will
try to upload my code to the repository and when I get a chance see how
it could integrate into the hub. And I should attend a meeting too... 

	On 9/28/07, Gideon Lee <glee at openspot.com> wrote: 

		My thoughts in blue.

			----- Original Message ----- 
			From: Howard Weingram
<mailto:weingram at tibco.com>  
			To: OpenAjax Alliance Security Task Force
<mailto:security at openajax.org>  ; 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
			B. Different upper level protocol
implementations could 
			in fact be layered over the same lower level,
			different lower level protocols could implement
			same lower level API. We should consider
			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
			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
<http://a.com/>  contains 2 B.com <http://b.com/>  contains A.com
<http://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
			F. (your #3) That kind of clicking is a royal
			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. 
			Best Regards,
			Howard Weingram


				From: security-bounces at openajax.org
[mailto: security-bounces at openajax.org
<mailto:security-bounces at openajax.org> ] On Behalf Of Gideon Lee
				Sent: Thursday, September 27, 2007 4:02
				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:
				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. 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. 



			interop mailing list
			interop at openajax.org



		interop mailing list
		interop at openajax.org 

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

More information about the security mailing list