Bug 20642 – Adopt opener restriction for top-level frame navigation

• Component: Frames
• Status: RESOLVED FIXED

[Adam Barth]

Both IE 8 beta 2 and Firefox 3 now support the "opener restriction" for navigation of top-level frames.  We discussed this a number of months ago when we did the initial frame navigation work, but opted not to implement the restriction.  Here is what it does:

Suppose window X opens window Y via window.open(...).  If window Z tries to navigate Y, the navigation will be blocked if Z is not the same origin as X (the opener of Y).

I'm not convinced the opener restriction actually prevents any real attacks, but it's probably worth matching the behavior of other browsers.  (Opera has a very complex policy for top-level windows, for example caring if a window is showing an HTTPS page or not).

For some older context, see http://crypto.stanford.edu/websec/frames/navigation/

[Sam Weinig]

I think this would be okay.  Does HTML5 define this behavior.  If not, we should suggest Ian change it to match.

[Adam Barth]

HTML 5 does spec the opener restriction, but the spec is subtly different from what Firefox implements.  Firefox only computes one level of recursion of "can navigate the opener," whereas a literal reading of the spec seems to suggest unbounded recursion.

[Adam Barth]

Created attachment 23224 [details]
patch

[Sam Weinig]

Comment on attachment 23224 [details]
patch

Looks good.  I would give a bit more of an explanation of the opener restriction is in the changlog as well as why we are adopting it (to match other browsers).

+    // Allow frame-busting.
This comment might be confusing to those not familiar with the term "frame-busting".

[Adam Barth]

Fixed in r36262.