- From: Adam Barth <hk9565@gmail.com>
- Date: Fri, 26 Oct 2007 15:51:51 -0700
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 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. 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. 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 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," 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. Adam [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