22319 2013-06-10 18:12:10 +0000 Should window.close() be affected by sandboxing restrictions? 2013-08-16 20:55:21 +0000 1 1 1 Unclassified WHATWG HTML unspecified All All RESOLVED FIXED P2 normal Unsorted 1 bobowencode ian ian imelven mike w3c zcorpan contributor oldest_to_newest 89004 0 1371 bobowencode 2013-06-10 18:12:10 +0000 Created attachment 1371 Test window.close() from sandbox - closeTestOpener.html starts the test. As part of discussions on bug 20939, I've been asked to raise this bug. The purpose is to look at whether window.close() should be affected by sandboxing rules. In the specification at http://www.w3.org/html/wg/drafts/html/master/browsers.html#dom-window-close, it states: "The close() method on Window objects should, if the corresponding browsing context A is script-closable and the browsing context of the script that invokes the method is allowed to navigate the browsing context A, close the browsing context A." The "allowed to navigate" rules at http://www.w3.org/html/wg/drafts/html/master/browsers.html#allowed-to-navigate, don't include the sandboxing rules, but sandboxing could actually affect whether navigation takes place. So the question is, if navigation of a browsing context is blocked by sandboxing rules, should window.close() also be blocked? I believe it should, as (for example) it seems wrong that a sandboxed browsing context is not allowed to navigate top, but is allowed to close it. I did a quick test to see what happens in a sandbox with allow-scripts, but not allow-top-navigation. closeTestOpener.html starts the test. (This test was done in early May, I'm sorry I don't have the versions that were used.) Firefox, IE10, Chrome and Opera all seem to block the direct navigation of top with window.open(..., "_top"). Only Chrome stops the window.top.close(). It gives the same error as for the navigation, which complains that you are trying to navigate top without allow-top-navigation. As I have said, Chrome's behaviour seems correct to me. Thanks, Bob 89005 1 bobowencode 2013-06-10 18:13:13 +0000 Ian - thought you would want to be included on this. 89038 2 ian 2013-06-10 23:03:47 +0000 Acting as devil's advocate: The difference is that navigation is about going to a new page, whereas close() is about closing the current page. Closing the current page is already only allowed in a very limited set of cases — where script opened the page in the first place, or where it's the only page that's been opened in that browsing context — and sandboxing can only close the page in the case where scripts are enabled despite sandboxing being used. But yeah, it seems like a sandboxed script shouldn't be able to close a tab. Do you want this blocked by the "sandboxed top-level navigation browsing context flag" (so you can reenable it with 'allow-top-navigation', meaning that an embedded sandboxed ad can close your whole page) or by the "sandboxed navigation browsing context flag" (so it's always blocked)? I'm leaning towards the latter. 89111 3 bobowencode 2013-06-11 18:29:29 +0000 (In reply to comment #2) > Acting as devil's advocate: > > The difference is that navigation is about going to a new page, whereas > close() is about closing the current page. Closing the current page is > already only allowed in a very limited set of cases — where script opened > the page in the first place, or where it's the only page that's been opened > in that browsing context — and sandboxing can only close the page in the > case where scripts are enabled despite sandboxing being used. > > But yeah, it seems like a sandboxed script shouldn't be able to close a tab. Thanks for the quick response. I do appreciate that closing is different to navigation, although perhaps closing can be thought of as navigating to dev://null :) I also agree that this probably isn't causing major problems, because, as you say, the restrictions on close() are already quite severe. It's more tidying up a loose end. > Do you want this blocked by the "sandboxed top-level navigation browsing > context flag" (so you can reenable it with 'allow-top-navigation', meaning > that an embedded sandboxed ad can close your whole page) or by the > "sandboxed navigation browsing context flag" (so it's always blocked)? I'm > leaning towards the latter. I was thinking of the former, just because it seems to tie in with the existing rules. By which I mean ... navigating top is normally allowed unless sandboxed and this restriction is lifted by allow-top-navigation. So, taking the other restrictions as read, as you can normally close because you are "allowed to navigate" top, it seems reasonable that you can when sandboxed with allow-top-navigation. I know that "allowed to navigate" isn't affected by sandboxing, but it makes sense to me. (I've also left a thought about the use of "allowed to navigate" as a term in bug 20939) Finally, given that you could navigate top to a non-sandboxed document and close anyway, it might be a little bit academic. I've just checked and Chrome allows you to close top with allow-top-navigation, but blocks it otherwise. Cheers, Bob 89435 4 ian 2013-06-18 00:23:48 +0000 (In reply to comment #3) > > Finally, given that you could navigate top to a non-sandboxed document and > close anyway, it might be a little bit academic. That's a pretty good point. Done. BTW, the spec I edit is the one at http://whatwg.org/html; the W3C one you cite is a fork that has a number of differences (some would call them "errors") in it. 89436 5 contributor 2013-06-18 00:24:09 +0000 Checked in as WHATWG revision r7984. Check-in comment: Sandboxing: prevent pages from closing their top-level browsing context (unless they can navigate it, in which case, whatever) http://html5.org/tools/web-apps-tracker?from=7983&to=7984 89764 6 1378 bobowencode 2013-06-24 18:31:33 +0000 Created attachment 1378 Test closing a window from a sandboxed iframe that didn't open it. Hi Ian, Really sorry about this ... you must be sick of me by now. I'd originally thought that this should cover all cases where navigation would be blocked by sandboxing. I've added another test case, which is possibly the only other relevant one anyway. In this one the sandboxed iframe is trying to close a top-level browsing context that is not its top. I've added an unsandboxed iframe to show the difference. Chrome seems to block the close from the sandboxed iframe, but IE and Firefox both allow it, while correctly blocking the navigation. Chrome doesn't seem to put out any sort of error, it just does nothing. For chrome you have to run the test from a proper web server, because it doesn't allow access to parent just from the file system - I think it sees them as from a different origin. So I think the conditions for being allowed to close should be something like: * The corresponding browsing context A is script-closable. * The browsing context of the incumbent script is allowed to navigate the browsing context A. * The active sandboxing flag set of the document of the incumbent script would not cause the navigate algorithm to abort the navigation of the browsing context A. The last point could link to the navigate algorithm. I'm sure you'd put it more eloquently though, I was try to avoid the words not allowed, because of the second bullet point. Cheers, Bob 89783 7 ian 2013-06-25 05:37:14 +0000 Are you saying in this case that it _should_ be able to close it, or that it _shouldn't_ be able to close it? I'm not sure I understand which you want and why you want it that way. 89791 8 bobowencode 2013-06-25 07:48:00 +0000 (In reply to comment #7) > Are you saying in this case that it _should_ be able to close it, or that it > _shouldn't_ be able to close it? I'm not sure I understand which you want > and why you want it that way. I knew that my wording needed some work. I mean that it shouldn't be able to close a browsing context if it is blocked from navigating it because of sandboxing. The reason is the same as for when it is your own top. It seems wrong that a browsing context is blocked from navigating another browsing context, but is allowed to close it. Hopefully, I've explained that more clearly, but I'm not convinced :) 90233 9 ian 2013-07-03 14:59:37 +0000 Oh, I see. I screwed up the way I used the sandboxing stuff. I need to basically use the same prose as in the navigation section: http://www.whatwg.org/specs/web-apps/current-work/#sandboxLinks Possibly by factoring that out. "Really allowed to navigate", or something... 90348 10 bobowencode 2013-07-04 12:32:19 +0000 (In reply to comment #9) > Oh, I see. I screwed up the way I used the sandboxing stuff. Well, I wouldn't say that. I should have been clearer, in Comment 3, that this was just an example. > I need to basically use the same prose as in the navigation section: > > http://www.whatwg.org/specs/web-apps/current-work/#sandboxLinks > > Possibly by factoring that out. "Really allowed to navigate", or something... That would make sense. Maybe a "Blocked from navigating" section. This could possibly go under "6.1.4 Security" and start something like: A browsing context A is blocked from navigating a second browsing context B if ... This would probably just include the sandboxing stuff at the moment. It could possibly be referenced from section "6.1.6 Browsing context names" as well as "6.6.1 Navigating across documents" and the bit on window.close(). Also, maybe the "allowed to navigate" could be renamed to "allowed to attempt to navigate", to make things really clear. Although that is a bit of a mouthful. You could then possibly remove the note on sandboxing that you added on my request for bug 20939 :) Cheers, Bob 90546 11 contributor 2013-07-09 22:25:31 +0000 Checked in as WHATWG revision r8045. Check-in comment: Stop one: rename 'allowed to navigate' to 'friends with' http://html5.org/tools/web-apps-tracker?from=8044&to=8045 90549 12 contributor 2013-07-09 22:39:11 +0000 Checked in as WHATWG revision r8046. Check-in comment: Factor out some steps from the top of the navigation algorithm to define 'allowed to navigate'. http://html5.org/tools/web-apps-tracker?from=8045&to=8046 90550 13 contributor 2013-07-09 22:45:51 +0000 Checked in as WHATWG revision r8047. Check-in comment: Change how window.close() decides what you can close to make more sense. http://html5.org/tools/web-apps-tracker?from=8046&to=8047 90552 14 contributor 2013-07-09 22:47:23 +0000 Checked in as WHATWG revision r8048. Check-in comment: Remove a note that is now more confusing than helpful. http://html5.org/tools/web-apps-tracker?from=8047&to=8048 90641 15 bobowencode 2013-07-11 18:58:44 +0000 Thanks Ian. I'm not sure about the term "friends with" as this implies a mutual relationship, which this is not. However paraphrasing from a reply on another bug ... unless a better term can be suggested then it should stand. Anyway, once you accept the term, then I think this all hangs together logically and is clearer than before. I did wonder whether there should be a line at the start of the new "allowed to navigate" algorithm stating: 1. If A is not friends with B, then abort these steps negatively. Just in case there is away that a browsing context can initiate a navigation on another browsing context without being friends. This doesn't appear to have been in the previous version, so I imagine it is OK. Cheers, Bob 91720 16 zcorpan 2013-08-07 11:40:40 +0000 Reopening to let Hixie ponder about comment 15 91749 17 ian 2013-08-07 21:29:15 +0000 (In reply to comment #15) > > I'm not sure about the term "friends with" as this implies a mutual > relationship, which this is not. > However paraphrasing from a reply on another bug ... unless a better term > can be suggested then it should stand. Yeah, I'm not a fan of the term either. The term implying a mutual relationship is an interesting point. I've tried renaming it to "is ". > I did wonder whether there should be a line at the start of the new "allowed > to navigate" algorithm stating: > > 1. If A is not friends with B, then abort these steps negatively. > > Just in case there is away that a browsing context can initiate a navigation > on another browsing context without being friends. Is there any way this can happen? (I don't like giving redundant requirements, because they tend to hide errors in the spec. Unlike software, which should have defense in depth because it's more important that it not break than that it be thought through all the way, in a spec it's more important that we do things intentionally and have it thought through all the way than that it not break. IMHO.) 91762 18 ian 2013-08-07 23:10:59 +0000 > relationship is an interesting point. I've tried renaming it to "is ". Er... "is familiar with". Just "is" would be a whole different ball game... 91764 19 contributor 2013-08-07 23:11:12 +0000 Checked in as WHATWG revision r8136. Check-in comment: Try renaming 'friends with' to 'familiar with'. http://html5.org/tools/web-apps-tracker?from=8135&to=8136 92185 20 bobowencode 2013-08-16 18:13:13 +0000 (In reply to comment #18) > > relationship is an interesting point. I've tried renaming it to "is ". > > Er... "is familiar with". Just "is" would be a whole different ball game... Sorry, I've been away on holiday, so I've not kept up with all of my mail. I think "is familiar with" works well. (In reply to comment #17) > (In reply to comment #15) > > I did wonder whether there should be a line at the start of the new "allowed > > to navigate" algorithm stating: > > > > 1. If A is not friends with B, then abort these steps negatively. > > > > Just in case there is away that a browsing context can initiate a navigation > > on another browsing context without being friends. > > Is there any way this can happen? (I don't like giving redundant > requirements, because they tend to hide errors in the spec. Unlike software, > which should have defense in depth because it's more important that it not > break than that it be thought through all the way, in a spec it's more > important that we do things intentionally and have it thought through all > the way than that it not break. IMHO.) Not that I've spotted, it was just a belt and braces thing. I've only really been looking at this part of the spec for sandboxing, so I'll have a think about it. Given we should have been through the rules for choosing a browsing context, then I don't immediately see how it can. If I come up with anything, I'll raise a new bug. Thanks, Bob 92187 21 bobowencode 2013-08-16 18:25:13 +0000 Sorry Ian, just noticed that the links in the table in 6.1.6 Browsing context names, still say "friends" instead of "familiar with". 92199 22 ian 2013-08-16 20:55:21 +0000 Thanks, good catch. 1371 2013-06-10 18:12:10 +0000 2013-06-10 18:12:10 +0000 Test window.close() from sandbox - closeTestOpener.html starts the test. closeTest.zip application/x-zip-compressed 1286 bobowencode UEsDBBQAAAAAAEyXykIAAAAAAAAAAAAAAAAKAAAAY2xvc2VUZXN0L1BLAwQUAAAACACilspCLdJX GxABAABlAgAAHgAAAGNsb3NlVGVzdC9jbG9zZVRlc3RJZnJhbWUuaHRtbJ1SPU/DMBDdkfgPx02J gGZFJekSKjHwNWRhQo7jNlYTO3IuVBHiv3NOQpFSCVX14Hune/f8fHZ89fCaZu9va3jMnp9Wlxdx SXU1RCUKjgBxrUiALIVrFSXY0eb2Dj0jmigMW+l0QwN90xlJ2hpwnXkRn3orSGWqpSCEL67zItcP cFh7bQq7X9hGmQBFbjta5pUwO7wB/CDbYHg/Ur9BCpIlBMq58K9fVMpRgGvnrPPK2myBLJjpZMbN EhCugdsOUhz8NrebVrY9wStLLqSnBud5873/G4ujw0A5yW3Rjy+Rd0RslfpGJTgmCNbISstdgkcD x1XqK1Cr+UjiaOw+UdYP5kjz9ypzQYZseADTX/oBUEsDBBQAAAAIAGKWykJviRvypQAAAPUAAAAe AAAAY2xvc2VUZXN0L2Nsb3NlVGVzdE9wZW5lci5odG1sbY89C8IwEIZ3wf9wZmoH7SqYdlFBQdGh II4xSWkhzYUmpYj4303S6uQt9/Xy3Ht0sbtsy/t1D4fyfCrmM1q7VsUsmfAZgLbSMeA166x0Oeld tVyToMgmiS8t7xrjorzqNXcNahBYSuuSFF5+7GNotMBhhUbqhHCFVob9bZyGqyTdBOU7oH9A3zxQ PAG1QiZy8qWS0ZspjhCI8A9IMxN9BkAspt8+UEsDBBQAAAAIALiWykKv24vNswAAAAMBAAAeAAAA Y2xvc2VUZXN0L2Nsb3NlVGVzdFdpbmRvdy5odG1sXY89C8IwEIZ3wf9w3tKptghCh6QgKigoOnRx TJvUFPpFc1L996ZJXVzuA573vffY6nDbZ4/7EU7Z9ZIuF0xTU7uuhLQdgDWKBBRaDEYRxxeVYYIT Ec2IHfNOfjzcpzswopV591YSqnIQjYKxIg2BqOtuDE0xVD2ZgEW9V8xMawtH0srv+HPhfzowQ8Gx qDujMmXo7Oj1lBrBip/aZkxitDclaY6bbYwpi7ypSz1ldcP86RdQSwECPwAUAAAAAABMl8pCAAAA AAAAAAAAAAAACgAkAAAAAAAAABAAAAAAAAAAY2xvc2VUZXN0LwoAIAAAAAAAAQAYAG/QthkEZs4B b9C2GQRmzgGZ1eMcv0nOAVBLAQI/ABQAAAAIAKKWykIt0lcbEAEAAGUCAAAeACQAAAAAAAAAIAAA ACgAAABjbG9zZVRlc3QvY2xvc2VUZXN0SWZyYW1lLmh0bWwKACAAAAAAAAEAGAA/DtpaA2bOAT8O 2loDZs4Bg821o/NIzgFQSwECPwAUAAAACABilspCb4kb8qUAAAD1AAAAHgAkAAAAAAAAACAAAAB0 AQAAY2xvc2VUZXN0L2Nsb3NlVGVzdE9wZW5lci5odG1sCgAgAAAAAAABABgARn++EgNmzgHsHLwS A2bOAZznds30SM4BUEsBAj8AFAAAAAgAuJbKQq/bi82zAAAAAwEAAB4AJAAAAAAAAAAgAAAAVQIA AGNsb3NlVGVzdC9jbG9zZVRlc3RXaW5kb3cuaHRtbAoAIAAAAAAAAQAYAPTZ2nQDZs4B9NnadANm zgEMgiXV80jOAVBLBQYAAAAABAAEAKwBAABEAwAAAAA= 1378 2013-06-24 18:31:33 +0000 2013-06-24 18:31:33 +0000 Test closing a window from a sandboxed iframe that didn't open it. notMyTopCloseTest.zip application/x-zip-compressed 1407 bobowencode UEsDBBQAAAAAAFaX2EIAAAAAAAAAAAAAAAASAAAAbm90TXlUb3BDbG9zZVRlc3QvUEsDBBQAAAAI AGqo10KP1Pwa+wAAAN4BAAAoAAAAbm90TXlUb3BDbG9zZVRlc3Qvbm90TXlUb3BDbG9zZVRlc3Qu aHRtbK2RPU/DMBCGdyT+w+GlIJGmggEETiRUkECigiELox27sYXji2yH0H+PE4cOXbp0ug/dPff6 Nb14/lhXX58v8Fpt3svzM6pCa6YomYgRgLYyMKgVc16GgvRhm92TcSKfR2Lqa6e7MI3/MAeDtgKH CtcGvYRirpfYSXtJGMc+PHDD7De5BjJozo0kV48jcc+JBUexSwK68gk8s4LjrxSgt461MjKDggUz BofMx0aGTjfaQuokkF/QvEuMtPWPKY4ugnd1QSyGza7CbnyIts3bBFmOFhFQUjcqGnK3IlGMCKog tzcrUtI83dprt9DbQ/kHuk5yjeajZVMyf+IfUEsDBBQAAAAIAGqo10JCJm+lKgEAAKsCAAAsAAAA bm90TXlUb3BDbG9zZVRlc3Qvbm90TXlUb3BDbG9zaW5nSWZyYW1lLmh0bWydUj1PxDAM3ZH4DyZT T0C7ImhvKScxcMDQhTFNfdeINqlSl6pC/Hfy0btDIKSKDLGt+Pk920kv7p/z4vVlAw/F9nF9fpbW 1DbeIq+sBUhbJA6i5qZHythAu+sb5jKSOcW6vTCyI5++G5QgqRWYQT3xd7nnhAX2FK3gw77bQ2by rj+jVJUeY92hipjStJ0K3QWcqxI7OewK2CjLskG2ugvATxCcRA0RGrM6VeMNGorYxhhtHI9UeyAN atZxCwwuwUKOZaxx10/heaP7Bao7blBRHKJCe1Qs3B39T6jHgqYazczxp+Q0OQ7dBqWuprCtciCy TdDUYcZCwEAr0UjxlrFfS2Hr3L18n9LMDHYb4PaCFZQTtJgmodxCnsMMTySHDpcwWNe25J35R34B UEsDBBQAAAAIAGqo10IV0YWXZgAAAHkAAAApAAAAbm90TXlUb3BDbG9zZVRlc3Qvbm90TXlUb3BO YXZpZ2F0aW9uLmh0bWwtzLkKgDAQRdFe8B9Ge7G1iDYqWLiBNpZjjAu4gJkI/r0mpHq3ODzmZU3a D20ORV+VieuwlY7drMDpXwB2CELgK95SUOwrmoPI1yK05M/xml6Da3y2BWm7TugU50LKWe3aGqHD /n9QSwECPwAUAAAAAABWl9hCAAAAAAAAAAAAAAAAEgAkAAAAAAAAABAAAAAAAAAAbm90TXlUb3BD bG9zZVRlc3QvCgAgAAAAAAABABgAze+zdgRxzgHN77N2BHHOAbJuTdpHbM4BUEsBAj8AFAAAAAgA aqjXQo/U/Br7AAAA3gEAACgAJAAAAAAAAAAgAAAAMAAAAG5vdE15VG9wQ2xvc2VUZXN0L25vdE15 VG9wQ2xvc2VUZXN0Lmh0bWwKACAAAAAAAAEAGABXTQy1THDOAZd1YQxNbM4B359O2kdszgFQSwEC PwAUAAAACABqqNdCQiZvpSoBAACrAgAALAAkAAAAAAAAACAAAABxAQAAbm90TXlUb3BDbG9zZVRl c3Qvbm90TXlUb3BDbG9zaW5nSWZyYW1lLmh0bWwKACAAAAAAAAEAGADe4A+1THDOASBuc6FMbM4B sm5N2kdszgFQSwECPwAUAAAACABqqNdCFdGFl2YAAAB5AAAAKQAkAAAAAAAAACAAAADlAgAAbm90 TXlUb3BDbG9zZVRlc3Qvbm90TXlUb3BOYXZpZ2F0aW9uLmh0bWwKACAAAAAAAAEAGAChqhG1THDO AQsSEbVMcM4BCxIRtUxwzgFQSwUGAAAAAAQABADXAQAAkgMAAAAA