[whatwg] window.opener and security

[Ian Hickson]

On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
>
> 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.

Indeed, this is now specced.


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

Using window.open() for this seems silly, this should just be a link.

I've made rel=noreferrer explicitly not include the opener as well as not 
including the Referer header. Does that address your use case?


On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
> 
> (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.)

I have not specified this, so this behaviour is currently non-compliant.


On Tue, 20 Mar 2007, Gareth Hay wrote:
> 
> 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.

Opening a window then poking with it then navigating it seems like a lot 
of effort when all you want to do is have a link open a window without it 
being associated with the opener.


On Tue, 20 Mar 2007, Gareth Hay wrote:
>
> 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.

window.opener in WebKit seems to be replaceable.


On Tue, 20 Mar 2007, Rimantas Liubertas wrote:
> 
> It was possible to set window.opener in IE, alas, I do not remember
> which version :(
> But it has been fixed, AFAIK.

Not as far as I can tell.


On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
> 
> I don't really see why setting opener would be dangerous, so I disagree 
> that it should throw.

On Tue, 20 Mar 2007, Gareth Hay 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?

On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
> 
> 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.

It's not really about use cases frankly, it's more about what browsers do 
today. Use cases are nice for new features but once pages rely on what 
browsers do, things become pretty immutable.

I've filed a bug to make sure that this is fixed once WebIDL allows us to 
fix it easily. (Right now the spec says the attribute is readonly.)

   http://www.w3.org/Bugs/Public/show_bug.cgi?id=5909


On Tue, 20 Mar 2007, liorean wrote:
> 
> The original problem is that browsers allow cross domain setting of 
> windowobject.location. Whether windowobject in this case comes from 
> window.opener isn't really relevant, except that it provides a method of 
> getting a windowobject reference.
> 
> Hallvord's solution is a workaround - it addresses the ability to get 
> that windowobject reference, even though it doesn't address the core 
> problem. [...]
> 
> 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.
> 
> Hallvord's solution of allowing sites to disable the window.opener 
> property and thereby preventing the writing to window.opener.location 
> does solve the problem for that particular window object, as an opt-in 
> security measure. The main problem I see with this approach is that if 
> people aren't nulling the window.opener property already I don't think 
> they would opt in for another alternative method of doing it. Actually 
> fixing cross domain writing to the location object would.

I don't think we can break these pages though.


On Tue, 20 Mar 2007, Gareth Hay wrote:
>
> It would appear that at least the WebKit team agree about the 
> window.opener being read-only.
> 
> It has resisted all attempts by me to null it or re-assign it, and as 
> soon as the domains no longer match exceptions are thrown.

I haven't been able to reproduce this. I seem to be able to set 'opener' 
without any problems.


On Tue, 20 Mar 2007, Martijn wrote:
> 
> I don't know what GMail is doing, but I think a
> window.open('','_self') would destroy the original window.opener.

On Tue, 20 Mar 2007, Hallvord R M Steen wrote:
> 
> That's a nice idea. It works in Firefox but fails in IE and Opera.

This wouldn't affect 'opener' according to the HTML5 spec today.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'