W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2007

[whatwg] HTML5 frame navigation policy

From: Adam Barth <hk9565@gmail.com>
Date: Fri, 26 Oct 2007 15:51:51 -0700
Message-ID: <9825acf0710261551i4bcf4356u76359128150b6ea2@mail.gmail.com>
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.

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.

The frame navigation policy in Firefox was developed in 1999 in
response to a similar attack against CitiBank [2].  Their policy is as
* 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.

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
* Allow if the source frame can script the target frame or one of its
ancestors in the frame hierarchy.

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.  We think the third bullet of item 4 in section 4.1.5 should

"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,"

where we intend "ancestor" to mean the transitive closure of the
parent relation.  This should (1) be more compatible with existing
sites as it is closer to current browser behavior and (2) not be any
less secure than the current spec because a frame that can script an
ancestor could have created a floating iframe and used it to simulate
navigating the target frame.


[1] http://www.whatwg.org/specs/web-apps/current-work/#the-rules
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=13871
[3] http://crypto.stanford.edu/~abarth/research/nav/frame1.html
[4] http://xenon.stanford.edu/~abarth/research/nav/frame1.html
Received on Friday, 26 October 2007 15:51:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:37 UTC