[whatwg] window.opener and security

[liorean]

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
> > properties, something defying the nature of JavaScript.
>
> 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
> <http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-258A00AF>)

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
JavaScript.

However, consider an access to foo.bar.baz. JavaScript will first
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
"http://phishing.exampe.net/evil"

In this, the setting of location happens on a window object.
JavaScript has no memory of how it got that window object, so
JavaScript itself cannot treat it specifically depending on how that
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
arbitrary depth) to all JavaScript instances not being contained in
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
objects.
-- 
David "liorean" Andersson