[whatwg] window.opener and security

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>)

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

-- 
Thomas Broyer

Received on Tuesday, 20 March 2007 09:18:09 UTC