I brought this up on the WHATWG list : http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/038149.html In my testing with Chrome, if you have a sandboxed document with the same origin as the top level document and the sandboxed document has 'allow-same-origin allow-scripts', the sandboxed document can NOT navigate the top level document via setting window.top.location ie it's blocked. Bobby Holley pointed out that blocking top navigation when the sandboxed document is same origin with the top level document is difficult, since the sandboxed document can do window.top.eval('window.location = "http://foo.com"') Doing this bypasses the block in Chrome and the top navigation happens. In IE 10, at least in the Windows 8 consumer preview which is the latest version i have at the moment unfortunately, you can set window.top.location from a document that's same origin with the top level document which is contained in an <iframe sandbox = 'allow-same-origin allow-scripts'> ie it doesn't need allow-top-navigation. I asked for some clarification in the WHATWG spec but none has happened to this date. One option would be for Webkit to also block the window.top.eval loophole, but in general we feel that trying to stop this when the documents are same origin would possibly be problematic. Another option would be to not block top navigation when the sandboxed document is same origin with the top level document (which implies it's been sandboxed with 'allow-same-origin' of course).
I'm assigning this to myself so that I don't lose it. Please feel free to steal it from me. I'm not going to be able to fix this tomorrow, but I'll take a look when I get back in Jan.
Given that a same-origin framed document with 'allow-scripts allow-same-origin' can already reach up into the parent frame, remove the 'sandbox' attribute, and reload itself, I'm not sure there's much value added by jumping through hoops to block `window.location` when executed inside `window.top.eval`. The spec makes it fairly clear that combining these flags with same-origin content is dangerous. What were you planning on fixing, Adam? I'm happy to take this while you're out, but it's not clear to me that there's a "right" solution. Blocking explicit navigation seems like we're making our best-effort to adhere to the sandbox flags, but I don't think we can plug all the mechanisms by which a malicious piece of same-origin content could bypass those flags while at the same time maintaining a sandboxed frame's access to its parent. Note, for instance, that you could bypass other flags this way as well: `window.top.eval('window.open();')` would get around a missing 'allow-popups' flag, and so on.
Hum... That's a good point. Ian, maybe the current behavior is more consistent?
(In reply to comment #3) > Hum... That's a good point. > > Ian, maybe the current behavior is more consistent? Sorry, I didn't see this question until just now ! I agree with Mike that it's not worth trying to block top navigation (or opening windows as I will mention shortly) when 'allow-same-origin' is specified. I know Bobby Holley agrees also and indeed first made this point to me. As Mike says "The spec makes it fairly clear that combining these flags with same-origin content is dangerous." - we want to add a warning in Gecko when these ineffective flags are specified even (https://bugzilla.mozilla.org/show_bug.cgi?id=752559) Just now while working on blocking navigating windows via script in iframe sandbox, I found you can do the same thing in Webkit (Chrome at least) with opening new windows without 'allow-popups' - ie. a.html has <iframe src='b.html' sandbox='allow-scripts allow-same-origin'> b.html does window.parent.eval('window.open('c.html')); The window is opened - but window.open would be blocked from b.html unless its sandbox attribute also included 'allow-popups'. In Gecko, based on discussions with Bobby, I'm not planning to try and block navigation of top level windows or opening new windows via script from documents that are sandboxed with 'allow-same-origin', only in the cross-origin case when doing so would be allowed if no sandbox attribute was present.
(In reply to comment #2) > Note, for instance, that you could bypass other flags this way as well: `window.top.eval('window.open();')` would get around a missing 'allow-popups' flag, and so on. I didn't read closely enough, Mike already pointed out the allow-popups issue as well :)
I realize I only partially agree with Mike as well - if you can trivially bypass the explicit restrictions, I'm not sure if they're useful.
(In reply to comment #6) > I realize I only partially agree with Mike as well - if you can trivially bypass the explicit restrictions, I'm not sure if they're useful. I don't think we should automatically remove all sandboxing restrictions just because a malicious page could do so easily. There are plenty of benign-but-buggy pages out there that could happily run in a minimally-effective sandbox for whom enforcement would be a benefit. I do agree that it's worthwhile to log a console warning for a same-origin sandbox with these flags, though. I'll see about making that happen.