[whatwg] HTML5 frame navigation policy

[Collin Jackson]

On Oct 26, 2007 3:51 PM, Adam Barth <hk9565 at gmail.com> wrote:
> Collin Jackson and I have been looking at the frame navigation policy
> of various browsers and have a suggestion for improving the frame
> navigation policy in the HTML5 spec.  As we understand the spec [1],
> it is stricter than IE7, Firefox 2, IE6, and Safari 3.

Since Adam sent this original email, we've been working with browser
vendors to deploy the Ancestor frame navigation policy in browsers. A
description of this policy can be found at
<http://crypto.stanford.edu/frames/>.

By adopting this policy, HTML5 will match Internet Explorer, Firefox,
and Safari.

> Internet Explorer 6 and Safari 3 have very permissive frame navigation
> policies that permit serious address-bar spoofing attacks on popular
> web sites.  For example, if a site asks for a user's password inside a
> frame (as many popular web sites do), an attacker can navigate the
> frame containing the password-entry field and steal passwords.

On December 18, 2007, Apple has deployed the Ancestor policy in Safari
as part of Security Update 2007-009 (CVE-2007-5858).

> The frame navigation policy in Firefox was developed in 1999 in
> response to a similar attack against CitiBank [2].  Their policy is as
> follows:
> * Allow the navigation if the source and target frames contained in
>    the same window.
> * Allow if the source frame can script the target frame or one of its
>    ancestors in the frame hierarchy.

On January 27, 2008, Mozilla adopted the Ancestor policy in Firefox 3;
see <https://bugzilla.mozilla.org/show_bug.cgi?id=408052>.

> Internet Explorer 7 is more strict than Firefox 2.  For example, IE7
> forbids the navigation from the lower frame in [3] whereas Firefox 2
> permits it.  From what we can tell, IE7 is enforcing the following
> policy:
> * Allow if the source frame can script the target frame or one of its
> ancestors in the frame hierarchy.

This is the Ancestor policy; Internet Explorer 7 already implements it.

> The HTML5 spec is the most strict.  From our reading, it forbids both
> of the navigations in [4], whereas all the browsers we've tested allow
> them.

HTML5 currently specifies the Parent policy:

> > 4.1.5. Browsing context names
> > ...
> > Or that browsing context is not a top-level browsing context, and the origin of
> > the active document of the parent browsing context of that browsing context
> > is the same as the origin of the current browsing context's active document,

We think it should be changed to the Ancestor policy. Opening a frame
to an origin can be viewed as delegating control of a portion of the
screen to that origin. If the active frame can script the target frame
or one of its ancestors, it has been delegated authority over the
target frame's portion of the screen and could simulate navigating the
frame by positioning a floating iframe on top of the target frame.

> We think the third bullet of item 4 in section 4.1.5 should read:
> "Or that browsing context is not a top-level browsing context, and the
> origin of the active document of *an ancestor* browsing context of
> that browsing context is the same as the origin of the current
> browsing context's active document,"

Here's a version that has the same meaning as Adam's original proposal
above, but uses the existing HTML5 "nested browsing context"
terminology rather than introducing the "ancestor" concept.

 Or that browsing context is not a top-level browsing context, and
 that browsing context is a nested browsing context of a browsing
 context whose active document's origin is the same as the origin
 of the current browsing context's active document,

Collin Jackson