[whatwg] window.opener and security

[Hallvord R M Steen]

On 20/03/07, Gareth Hay <gazhay at gmail.com> wrote:
> Well, window.opener is conceptually a link from child to parent.
> Can you give a valid use-case for adoption of the child to another
> parent?

Again: We are off-topic. This isn't what I'm trying to discuss in this thread.

However, here are two use cases for you:

1) I don't want the next page to mess with opener:

window.opener=null;
location.href='http://some-untrusted-location/';

(basically what sites should do today to work around the phishing
potential issue, but AFAIK none do.)

2) I have contents in an IFRAME that I want to talk directly to MY opener:

document.getElementsByTagName('iframe')[0].contentWindow.opener=self.opener;

What are your "exploit cases" where setting .opener is so dangerous
that it should throw? Note that making it throw also means being
backwards incompatible with

var opener='Once upon a time, ';

which might be far-fetched but certainly will exist somewhere if
browsers haven't thrown exceptions so far.

Now if you  have time I'd like some comments on the proposal

window.open(url,name, 'openerproperty=0');

;)

> On 20 Mar 2007, at 13:00, Hallvord R M Steen wrote:
>
> > On 20/03/07, Gareth Hay <gazhay at gmail.com> wrote:
> >> window.opener should be read-only and attempting to write to it
> >> should throw an exception.
> >
> > I don't really see why setting opener would be dangerous, so I
> > disagree that it should throw. Anyway, that is a different issue. What
> > I'm talking about is the built-in behaviour - the browser itself sets
> > window.opener in all popups, and there is currently no way to open a
> > popup that is prevented from changing the location of its opener.
> >
> > (An exception is Opera applying a stricter security policy if the
> > opener is an https page so in this case popup can't set location of
> > its opener, but I'm not sure if the other UAs do this.)
> >
>
>


-- 
Hallvord R. M. Steen