[
https://issues.apache.org/jira/browse/SHINDIG-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hjelmstad updated SHINDIG-416:
-----------------------------------
Attachment: rpc.js.nix-safe-handshake
Old patches removed, updated patch attached.
Because window.opener can be set by anybody, but read only by the gadget
IFRAME, we can rely on the auth token to secure the connection "handshake" done
through the object set there.
I've implemented this handshake as follows:
* window.opener set by parent to NIX wrapper
* gadget stores window.opener property in a local variable
* gadget verifies that handler.GetAuthToken() matches that provided by the
container
* if token matches, channel is created using this same object
MITM attacks should not be possible since they won't be able to read the
wrapper, and thus can't discern the auth token. Since the gadget has a handle
to the window.opener property, there's no attack possible in between the
AuthToken check and the CreateChannel call.
> Implement window.opener-based IE transport ("NIX") in gadgets.rpc
> -----------------------------------------------------------------
>
> Key: SHINDIG-416
> URL: https://issues.apache.org/jira/browse/SHINDIG-416
> Project: Shindig
> Issue Type: Improvement
> Components: Features (Javascript)
> Reporter: John Hjelmstad
> Assignee: John Hjelmstad
> Attachments: rpc.js.nix-safe-handshake
>
>
> Joey Schorr and I have been developing a technique for high-speed
> cross-domain message passing in IE6 and IE7 that exploits an odd property:
> for a given window object, window.opener can be set by any party, but only
> read by the controlling window.
> The message-passing technique is to pass a "channel creation" object from the
> container, across domain boundaries, to the gadget. The gadget uses this
> object to establish a bi-directional communication channel used by all
> subsequent gadgets.rpc calls.
> We can't pass a JavaScript object through window.opener, however, because
> doing so enables access to the passing agent's full window context. Eg. if
> the container sets window.opener = function() { ... }, then the gadget can
> access the entire container page with:
> var containerWindow = (new window.opener.constructor("return window;"))();
> Instead, we pass a VBScript (COM) wrapper through window.opener, since COM
> objects don't have this property. The gadget passes back such a wrapper as
> well, ensuring mutually isolated contexts.
> Patch forthcoming.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
