[whatwg] A potential slight security enhancement to postMessage

[Ian Hickson]

On Wed, 30 Jan 2008, Jeff Walden wrote:
>
> I briefly wrote up some documentation on postMessage for the Mozilla 
> Developer Center:
> 
> http://developer.mozilla.org/en/docs/DOM:window.postMessage
> 
> If you pull it up, you'll note two places where I include big, huge, 
> overbearing, somewhat-exaggerating injunctions about first checking the 
> domain/uri/source properties of the received message before trusting the 
> sent data.
> 
> Writing those got me thinking: what if we could "enforce" not touching 
> the data before verifying the sender's identity?  Specifically, what if 
> we required that either .domain or .uri be read prior to allowing .data 
> to be successfully accessed, say, without throwing a security error?  
> (No reason comes to mind for .source to participate in this scheme, 
> either to throw or to allow access to .data, but I haven't given it 
> serious thought.)  This would prevent unknowing misuse of this 
> functionality, and safe uses wouldn't be affected.  I think this would 
> only apply to the event dispatched by postMessage, not to MessageEvent, 
> as the latter is same-origin and there's no harm to a same-origin 
> MessageEvent.
> 
> Thoughts?  A no-harm slight increase of the ability to prevent incorrect 
> use of postMessage, or excessive nannying?

I think most uses of this are actually going to be accepting connections 
from any domain. I don't think it makes sense to require people who are 
just exposing an interface to the world to require people to go through 
hoops like this.


On Wed, 30 Jan 2008, Maciej Stachowiak wrote:
> 
> The more convenient version of that would be to require clients to 
> describe allowed senders when registering for the event in some way. 
> That would seem more like a convenience and less like a hoop to jump 
> through.

That's an option, but I fear that people would just end up calling 
allowAnyone() (or whatever we call it) in a cargo-cult fashion, 
undermining any security benefit.


On Thu, 31 Jan 2008, Jeff Walden wrote:
> 
> The key, tho, is that this really isn't a hoop to jump through.  
> Excluding toy "public message board" demos, can you describe a use case 
> for postMessage where it is not necessary to know the identity of the 
> sender?  To know the identity you have to check domain or uri, and 
> there's no reason not to do that before getting the sent data.

Almost all cases I intend to use this API for are open to anyone to embed. 
Game components, widgets, etc, none of them really care who is embedding 
them.


On Thu, 31 Jan 2008, Aaron Boodman wrote:
> 
> Not necessarily. You could do something like this:
> 
> window.createMessageReceiver("http://www.google.com")
>     .addEventListener("post-message", function() {
>   ...
> }, fase);
> 
> Could probably come up with a better method name, and I forget the name 
> of the event to use with PostMessage, but I hope you get the idea.
> 
> I like Maciej's suggestion of making it a natural part of the interface. 
> If you tell people they have to read x property before y property, they 
> will just do:
> 
> // spec says we have to read this first
> var foo = event.domain;
> alert(event.message);

But then people will just end up doing:

   window.createMessageReceiver("*").addEventListener('message', foo, false);

...without understanding what the createMessageReceiver() part is about. I 
don't think we'd really gain anything, except for slightly slowing things.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'