[whatwg] postMessage's target origin argument can be a full URL in some implementations
Hallvord R M Steen
hallvors at gmail.com
Tue Jul 20 12:18:25 PDT 2010
>> 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
> 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..
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...
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:
Hallvord R. M. Steen
More information about the whatwg