W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2010

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

From: Hallvord R M Steen <hallvors@gmail.com>
Date: Tue, 20 Jul 2010 21:18:25 +0200
Message-ID: <AANLkTikSI7vwSRsILOrJKyovQYyOpFQxEvObQIekvvp8@mail.gmail.com>
>> 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
Received on Tuesday, 20 July 2010 12:18:25 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:25 UTC