[whatwg] postMessage: event.source allows navigation of sender
Hallvord R M Steen
hallvors at gmail.com
Thu Feb 7 01:59:26 PST 2008
On 07/02/2008, Thomas Broyer <t.broyer at gmail.com> wrote:
> On Feb 7, 2008 10:24 AM, Hallvord R M Steen wrote:
> > Adam Barth and Collin Jackson pointed out to me that while
> > investigating frame navigation policies they found that a recipient of
> > a postMessage in Opera can set event.source.location, thus navigate
> > the sender window/document. I think this is a bug in the API itself.
>
> If what you say is true (see below) I'd rather say it's a bug in
> Opera's implementation.
That is of course a possibility. I don't have Firefox 3 handy so I'd
appreciate somebody explaining how it is implemented there.
> Shouldn't event.source.location be read-only? Isn't that a direct
> application of the same-origin policy?
No, all user agents I know allow you to set window.location across
domains. Not doing so would break literally millions of web pages. As
event.source just points to the sending window object setting
event.source.location is same as setting window.location .
> The current draft contains the following note:
> "Implementors are urged to take extra care in the implementation of
> this feature. It allows authors to transmit information from one
> domain to another domain, which is normally disallowed for security
> reasons. It also requires that UAs be careful to allow access to
> certain properties but not others."
Do you really thing this vague paragraph *can* be interpreted as
saying normal same-domain policies should be extended with a stricter
policy that also disallows setting location? It's not exactly clear.
> See also http://www.whatwg.org/specs/web-apps/current-work/multipage/section-history.html#security5
>
> And setting the event.source (Window object)'s location property is
> covered by the following paragraph:
> "In the ECMAScript DOM binding, the location members of the
> HTMLDocument and Window interfaces behave as if they had a setter:
> user agents must treats attempts to set these location attribute as
> attempts at setting the href attribute of the relevant Location object
> instead."
Indeed. All UAs already do that - if you set location, you set .href.
Have a look at section 4.7.4.1. Security which reads:
User agents must raise a security exception whenever any of the
members of a Location object are accessed by scripts whose origin is
not the same as the Location object's associated Document's origin,
with the following exceptions:
* The href setter
So setting location actually sets href, and setting href is explicitly
permitted across domains. By my reading the spec clearly dictates what
Opera has implemented, so the original question remains.
--
Hallvord R. M. Steen
More information about the whatwg
mailing list