[whatwg] window.opener and security

[Gareth Hay]

Well, I don't think it is off-topic.
You are trying to justify writing to a property I think should be  
read-only.
I am asking you why you think this should be possible.

Anyway, for use case 1 - If you are worried about phishing attacks,  
you should be using some sort of
onunload handler trapping to null window.opener. Then you can be sure  
it won't be absued by anyone, even
if the user leaves your site by typing in a new uri.

For case 2, you have an iframe in a popup wanting to communicate with  
the opener?
what is wrong with window.opener.opener ?

I personally think that as soon as the domain changes the UA should  
null window.opener, but if it doesn't you can work around it as I  
said, and I think you have a non-existent problem in case 2.

*back to topic*

I don't think you need this property, you are free to send null to  
the child window's opener as things are now, and I would argue for  
making the property read-only in any future spec anyway, making the  
UA responsible for security.

Gareth

On 20 Mar 2007, at 13:21, Hallvord R M Steen wrote:

> 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