[whatwg] More on postMessage
mjs at apple.com
Mon Jul 16 19:11:59 PDT 2007
On Jul 16, 2007, at 12:17 PM, Jeff Walden wrote:
> Gorm Haug Eriksen wrote:
>> I agree that postMessage should have been on the window and not on
>> the document, but why would you like to have the method on
>> yourWindow instead of the otherWindow you post the message to?
> The benefit is that you don't have to punch holes through your
> existing security infrastructure to do it. If you're in your code,
> you can have a reference to an |otherWindow| that's not same-origin
> as you, but you can't do any of the following (and probably more)
> with it:
> var secretProperty = otherWindow.secretProperty; // stolen!
> for (var i in otherWindow)
> // if you get here, you know some of otherWindow's
> // properties -- information leak
> otherWindow.trustedProperty = "subverted"; // oops!
> delete otherWindow.importantInfo; // DOS
> For you to need to use postMessage on otherWindow, you need to be
> able to do many of these things -- but the entire browser security
> model is based on not allowing you to do this if the window you've
> called it on isn't same-origin with you. You have to punch a hole
> in this security to allow getting, calling, or enumerating
> postMessage, but only if the object off which the property is gotten
> is a Window.
There's already a handful of Window properties and methods where
access bypasses the normal cross-domain security checks, such as the
close() method and the closed property. So this isn't a new concept.
In WebKit at least we handle these domain security exceptions in a
unified way, and adding one more method that works the same way would
not be a big deal.
> You also have to make the property appear ReadOnly/DontDelete
> externally, so you can't screw with windows that try to call
> postMessage on you. Also, how does this restriction work with other
> windows which are same-origin? Do they see only the original
> postMessage binding, or do they see any modifications that window
> makes to it? What if a different window, same-origin, makes that
> modification? What if windows pre-HTML5 wanted to communicate via a
> postMessage binding? This gets complicated pretty quickly, and to
> do it all you have to punch a hole through security, and with the
> fragility of that hole (only on Window, only if "postMessage", only
> with the original binding or only if it hasn't been overridden --
> and I'm not at all sure that's enough) and the specific criteria for
> that hole to exist, it's going to be easy to accidentally allow more
> than you wanted to allow.
I don't think that's the case, given that browsers must already
implement the other exceptions.
> In contrast, passing a different-origin value into a function is
> already allowed, and you don't need to do anything special to make
> it possible. The only security modification to allow the cross-
> origin-ness is to make postMessage ignore origins. This is *vastly*
> simpler, easier to implement, and hence safer and more secure.
> I'll agree that calling postMessage on the other window feels like a
> better and more intuitive API for users, but if implementers have to
> make such invasive and potentially-unsafe changes to do it, I think
> it's the wrong way to do it.
I would say go with the simpler API, since I don't think either way
creates extra implementation difficulties.
More information about the whatwg