Cannot windown.close() window opened from sandboxed frame
Reported by
justin.m...@tibit.com,
Mar 24 2016
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/47.0.2526.106 Chrome/47.0.2526.106 Safari/537.36 Steps to reproduce the problem: 1. Go to http://codepen.io/tibit/pen/remQwm/ 2. Click open button 3. Observe Popup window opens at same URL as Opener 4. Wait 3s (setTimeout( popupClose, 3000);) 5. Observe Popup window remains open 6. Observer error in console What is the expected behavior? The Popup window should close, as the Opener is the "one permitted sandboxed navigator" that such Popups "always have" per the HTML5 spec. Tested and works as expected in: FireFox 43.0.4 (Linux Mint) MS Edge 25.10586 (Windows) MS IE 11.103 (Windows) What went wrong? The Popup window can not be navigated by the Opener, which is inconsistent with the HTML5 spec. The Opener window console reports "The frame attempting navigation is sandboxed, and is therefore disallowed from navigating its ancestors." however the Popup it opened should not be regarded as an ancestor. Did this work before? N/A Chrome version: 47.0.2526.106 Channel: stable OS Version: Mint 17.2 Flash Version: Shockwave Flash 11.2 r999 https://www.w3.org/TR/html5/browsers.html#security-nav (5.1.4 Security) Opener is 'familiar' with Popup as they have the same origin. The Popup is a top-level browsing-context. The Popup is not an ancestor browsing-context of the Opener. The Opener should be the "one permitted sandboxed navigator of" the Popup (5.4 Sandboxing) The "sandboxed auxiliary navigation browsing context flag" should not be set, as the "allow-popups" keyword is set on the Opener. "If the sandboxed auxiliary navigation browsing context flag is not set, then in certain cases the restrictions nonetheless allow popups (new top-level browsing contexts) to be opened. These browsing contexts always have one permitted sandboxed navigator, set when the browsing context is created, which allows the browsing context that created them to actually navigate them. (Otherwise, the sandboxed navigation browsing context flag would prevent them from being navigated even if they were opened.)"
,
Mar 24 2016
Reproduced on latest Canary. I don't think this poses a security impact to users, since we seem to actually be over-restricting the access. So this is merely a bug, so unrestricting. Also, japhet seems to be a good owner for this.
,
Mar 24 2016
,
Nov 22 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/53f3802c16e36675a690990d8d8b616e31817c0f commit 53f3802c16e36675a690990d8d8b616e31817c0f Author: japhet <japhet@chromium.org> Date: Tue Nov 22 21:56:43 2016 window.close() should work from a sandboxed iframe if iframe is opener BUG= 597641 Review-Url: https://codereview.chromium.org/2399713002 Cr-Commit-Position: refs/heads/master@{#433998} [add] https://crrev.com/53f3802c16e36675a690990d8d8b616e31817c0f/third_party/WebKit/LayoutTests/http/tests/security/popup-allowed-by-sandbox-can-navigate-expected.txt [add] https://crrev.com/53f3802c16e36675a690990d8d8b616e31817c0f/third_party/WebKit/LayoutTests/http/tests/security/popup-allowed-by-sandbox-can-navigate.html [add] https://crrev.com/53f3802c16e36675a690990d8d8b616e31817c0f/third_party/WebKit/LayoutTests/http/tests/security/sandboxed-opener-can-close-window-expected.txt [add] https://crrev.com/53f3802c16e36675a690990d8d8b616e31817c0f/third_party/WebKit/LayoutTests/http/tests/security/sandboxed-opener-can-close-window.html [modify] https://crrev.com/53f3802c16e36675a690990d8d8b616e31817c0f/third_party/WebKit/Source/core/frame/Frame.cpp
,
Nov 23 2016
|
||||
►
Sign in to add a comment |
||||
Comment 1 by wfh@chromium.org
, Mar 24 2016Owner: mkwst@chromium.org
Status: Assigned (was: Unconfirmed)