[whatwg] window.opener and security

[Gareth Hay]

window.opener should be read-only and attempting to write to it  
should throw an exception.

This is a similar issue to window.history, in certain browsers you  
can write to this with js. It has no effect, but does persist across  
domains. The webkit team decided to just throw an exception if a  
write to window.history was detected. I don't know if it ever got  
implemented, or even if any of the other browser vendors addressed it.

On 20 Mar 2007, at 11:40, Hallvord R M Steen wrote:

> Hi,
> when a new window or tab is opened by a page it normally has a
> "window.opener" property that points to the window object of the
> original tab.
>
> This happens whether the new window is opened by a JavaScript calling
> window.open or by a link or form with target attribute set.
>
> If an origin check fails when comparing the locations of the old
> window and the popup, the normal cross-domain security policies apply.
> This means that popup contents from a different site will not be
> allowed to call methods or manipulate the DOM of the opener.
>
> However, this cross-domain security policy has one exception: the
> popup may set the location of its opener. This has phishing potential,
> particularly for webmail where opening external links in a new window
> is a very common use case. Hence I think it would be a good idea to
> let a site opt-out and specify that the popup should not have a
> window.opener property. For example, one could extend the "features"
> argument of window.open:
>
> window.open(url, name, 'openerproperty=0');
>
> Thoughts?
>
> References:
> http://my.opera.com/hallvors/blog/2007/03/14/window-opener-and- 
> security-an-unfixable-problem
>
> -- 
> Hallvord R. M. Steen