[whatwg] HTML5 frame navigation policy
ian at hixie.ch
Tue Jul 29 18:37:16 PDT 2008
On Tue, 29 Apr 2008, Adam Barth wrote:
> A couple points about Section 4.1.4:
> 1) The spec, as written, prohibits frame-busting.
> Test case: <http://crypto.stanford.edu/~abarth/research/html5/frame-busting/>
> Browser behavior:
> * Internet Explorer 8 beta: Navigation allowed.
> * Firefox 3 nightly: Navigation allowed.
> * Safari 3.1: Navigation allowed.
> * Opera 9: Navigation allowed.
> Frame-busting is used by many sites, including the Yahoo sign-in page.
> The Yahoo sign-in page uses frame-busting to avoid showing it's trusted
> sign-in image while being framed by an attacker (who can overlay his own
> password field on top of Yahoo's).
Defined window.top, and allowed nested browsing contexts to navigate its
top-level browsing context.
> 2) The spec reads "The browsing context B is an auxiliary browsing
> context and either its opener browsing context is A or A is allowed to
> navigate B's opener browsing context." This is redundant because if B's
> opener browser context is A, then A is allowed to navigate B's opener
> browsing context.
> 3) Consider the following set of frames. A opens X, which opens B.
> Now A attempts to navigate B.
> Test case: <http://crypto.stanford.edu/~abarth/research/html5/transitive-opener/>
> Browser behavior:
> * Internet Explorer 8 beta: Navigation allowed (IE does not implement
> an opener restriction).
> * Firefox 3 nightly: Navigation denied.
> * Safari 3.1: Navigation allowed (Safari does not implement an opener
> * Opera 9: Navigation denied.
> The spec allows this navigation because it says "A is allowed to
> navigate B's opener browsing context." Now, A is allowed to navigate X
> (by this rule), which means A is also allowed to navigate B (by a second
> application of this rule).
The theory being that if X can navigate B (because B is an auxiliary
context opened by X), then all A has to do is navigate X to something that
contains code that navigates B, so we might as well allow A to navigate B
> I don't have access to the Opera source code, but Firefox's opener
> restriction computes just one level of recursion. Note the branch at
> and that the function passes PR_FALSE for the parameter aConsiderOpener
> when it calls itself recursively.
The above logic can be extrapolated to any number of levels, so I don't
see any reason to limit it to one level of recursion.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg