[whatwg] window.opener and security
liorean at gmail.com
Tue Mar 20 19:33:55 PDT 2007
On 20/03/07, Thomas Broyer <t.broyer at gmail.com> wrote:
> 2007/3/20, liorean:
> > Some thing I would like to add here, is that your "solution" doesn't
> > do anything to solve the actual l problem case. Even if window.opener
> > would be read only, that is just a reference to a window object. Even
> > if that property would be read only you could still write to the
> > location property of the window object it references. For your
> > solution to work the read only attribute would have to cascade to all
> I'm not so sure.
> And this would be similar to a node being read-only in the DOM (see
> the NO_MODIFICATION_ALLOWED_ERR DOMException in
In the case of writing to windowobject.location, yes. Then it would
work just like that, because just like the DOM exception you talk
about, the cross domain security checks lay in a deeper layer than
access the first variable foo it can find in the current scope. When
found, it will access the first bar property it can find in the
prototype chain of the object referenced by that variable. And
finally, it will access the first baz it can find in the prototype
chain of the object referenced by that property.
In other words, the access to baz will operate on an object already
extracted from the bar property of an already extracted object from
the foo variable. All of these accesses only operate on one object,
how that object was originally gotten to has already been forgotten
when that access takes place.
Similarly, for window.opener.location="http://phishing.exampe.net/evil"
1. Access the "window" variable in current scope chain.
2. Set the working object to the value of that variable.
3. Access the "opener" property of the working object.
4. Set the working object to the value of that property.
5. Set the "location" property of that object to the string
In this, the setting of location happens on a window object.
was. However, the implementation of the property getters/setters in
this example can themselves apply security checks and/or give a
wrapped object with security restrictions. That's where the solution
to this fix belongs.
> > A much better solution, in my opinion, would be to make the location
> > object safe from cross domain attacks by making it only writable from
> > same domain, or if the document does not have a domain yet.
> > (window.open without address) I do think this would break some sites,
> > however.
> Yep, e.g. redirecting to a mirror-site.
> But this is a very interesting idea (similar to XMLHttpRequest not
> allowing cross-domain requests; you'd just need a page on the same
> level to issue redirects at the HTTP-level to word-around that new
> limitation; and this is a really sane work-around IMO).
> I would personally combine both suggestions: window.opener, window.top
> and other windowobject accessors return readonly objects when called
> from a page within a different domain; and within the page, constrain
> window.location setting (imagine someone hacks Google and adds a
> window.location=XXX in Google Analytics script).
Or, they don't actually access window objects. They return security
restriction wrapper objects for those window objects, and these give
similar security restriction wrapped objects (recursively for
their window object. This way the read/write access can be dynamically
changed depending on any security restriction factor. It incurs a
slight cost for all cross frame/window scripting (compared to scripts
contained in the same window object), but I would think some mechanism
like this is already in place in browsers, at least for some specific
David "liorean" Andersson
More information about the whatwg