- From: Brad Hill <hillbrad@gmail.com>
- Date: Wed, 07 Jan 2015 18:58:57 +0000
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAEeYn8j5nxSyuMT+EsGi7=OedxUqTs_WCQiaC9ABXkfcrXDhVw@mail.gmail.com>
This bug has come to my attention: https://code.google.com/p/chromium/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=&id=168988 Basically, Site X has a link to Site Y that opens in a new tab. Site Y can then use window.opener.navigate to change the tab that used to contain Site X to something else in the background. The user may not notice this switcheroo and can be possibly exploited when they go back to the tab expecting it is still Site X. The only current mitigation is for Site X to open the new tab to a location it controls first, use script to disown window.opener, then programmatically navigate to the final location at Site Y. This is very slow. :( It's not an exact fit, but (if the WHATWG declines or the compat impact is deemed too big to break this behavior cross-origin by default) I wonder what people think of possibly adding an additional directive to referrer-policy, "disown-window-opener", that instructs the user agent to apply https://html.spec.whatwg.org/#disowned-its-opener automatically as it performs a navigation. -Brad
Received on Wednesday, 7 January 2015 18:59:25 UTC