CSP3: Add something along the lines of `disown-window-owner`.

[mikewest]

@hillbrad suggested adding a disown-window-owner flag of some sort to execute https://html.spec.whatwg.org/#disowned-its-opener automagically when opening auxiliary browsing contexts. That seems reasonable, but we'll need to bikeshed the name/syntax a bit:

1. We're not disowning the owner of this window, we're asking windows we create to disown their owners.
2. Should this be a valueless property, or should we bundle things like this and mixed content's strict mode somehow? e.g. default-src 'self'; clever-directive-name disown-window-owner strict-mixed-content-checking?

Thread: http://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0071.html

[hillbrad]

Nit: the property is window.opener, so "disown-window-opener".

On Thu Jan 08 2015 at 1:05:10 AM Mike West notifications@github.com wrote:

@hillbrad https://github.com/hillbrad suggested adding a
disown-window-owner flag of some sort to execute
https://html.spec.whatwg.org/#disowned-its-opener automagically when
opening auxiliary browsing contexts. That seems reasonable, but we'll need
to bikeshed the name/syntax a bit:

1. We're not disowning the owner of this window, we're asking windows
   we create to disown their owners.
2. Should this be a valueless property, or should we bundle things
   like this and mixed content's strict mode somehow? e.g. default-src
   'self'; clever-directive-name disown-window-owner
   strict-mixed-content-checking?

Thread:
http://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0071.html

—
Reply to this email directly or view it on GitHub
#139.

[cure53]

Why would this be a security-opt-in?
Wouldn't it be better to categorically destroy window.opener for any cross-origin navigation?

We currently have the problem, that browser vendors (the Chrome team) recommend to use <a rel="noreferrer"> to destroy window.opener. This is however fairly pointless as rel doesn't apply to anchors inside SVG, forms, buttons etc. - but only HTML anchors and areas.

[cure53]

And I am not even talking about MathML on Firefox yet ;)

[mikewest]

Because everything in CSP is an opt-in. Sites rely on the current behavior of non-rel=noreferrer links (every OpenID/Single Sign On popup window you've ever seen, for instance). I don't think we can break that without an opt-in.

[cure53]

@mikewest Fair enough. Btw, I added some examples about links and link-likes that bypass rel=noreferrer: http://html5sec.org/#143

<a href="//evil.com" target="_blank" rel="noreferrer">CLICK</a> // window.opener will be null
<map><area href="//evil.com" target="_blank" rel="noreferrer">CLICK</area></map> // window.opener will be null 

<svg><a xlink:href="//evil.com" rel="noreferrer">CLICK</a></svg> // window.opener still works 
<form action="//evil.com" target="_blank" rel="noreferrer"><input type="submit"></form>// window.opener still works 
<form id="test" rel="noreferrer"></form><button formtarget="_blank" formaction="//evil.com">CLICKME</button>// window.opener still works 
<math href="//evil.com" xlink:show="new" rel="noreferrer">CLICKME</math>// window.opener still works

[jeisinger]

how does this relate to https://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts

[mikewest]

1. We should probably implement something like that. noreferrer + _blank is a hack.
2. The CSP directive would, I assume, apply to all navigations/windows from a page.

[jeisinger]

sounds like a bug.

doesn't sound that bad: why would you submit stuff to a site but not trust it?

[jeisinger]

sounds like a bug, I meant

[jakearchibald]

If my page is a non-secure context only due to the presence of window.opener, is window.opener = null enough to make my page secure?