[whatwg] postMessage's target origin argument can be a full URL in some implementations

[Hallvord R M Steen]

>> I agree with that in general, however it makes things harder that this
>> is an issue that might have security implications.
>
> The security implication being that authors might get confused about what
> the origin actually means and whom they can expect messages from, right?

More precisely who they can send messages too. An author writing a
script to run on e.g. sites.google.com/site/foo migh use postMessage
for private data intended for other pages on his site, and believe
that specifying the target origin http://sites.google.com/site/foo
would prevent sites.google.com/site/bar from listening in.

>> Facebook uses it in a "clever" way to actually pass on some GUID/data
>> in the path, which will presumably appear in e.origin in the message
>> listener?
>
> e.origin is the origin the event originated at.  It's computed by the
> browser, and is entirely independent of the arguments passed to postMessage.
>  In Gecko's case, this is computed using the "compute an origin" URI in the
> HTML5 spec.

That is the way I thought it worked, so now I am pretty curious what
the point of the FB code I saw is..

http://connect.facebook.net/en_US/all.js :

FB.XD._origin=(window.location.protocol+'//'+window.location.host+'/'+FB.guid());

But I guess they might use this FB.guid() part in other ways to do
cross-document messaging within this same library.

> The only thing the string passed to postMessage is used for is same-origin
> comparisons when deciding whether to deliver the event at all.  And of
> course same-origin comparisons don't depend on the path portion of the url;
> I would expect every single web developer who knows what a same-origin
> comparison is to know that...

OK.

Adam Barth wrote:

>  If I were to rate this as a security vulnerability, I'd rate it as
> SecSeverity-None, which means I wouldn't even issue an advisory for it.

Fine, we will change it on our side, and I commented on the spec:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10211

-- 
Hallvord R. M. Steen