Surfacing the browser's cross-frame-scripting policy in the chrome

Hi all,

AFAICT, our current rec doesn't reflect the browser's cross-frame scripting policy in the recommended chrome presentation. For example, a browser may have a window open on a page at www.example.com that is only weakly TLS-protected, while another window, open on a page at the same domain, is strongly TLS-protected with an AA certificate. Under the current rec, the browser could present the first window with no identity signal information, while presenting the second window with web page owner information. Since the browser permits each of these windows to script the other, the distinction in presentation doesn't reflect any actual security boundary. A network-level attacker could exploit this discrepancy as follows.

User visits a page controlled by the attacker at evil.com. This page directs the user to a page at https://victim.com/attacker. The attacker intercepts this network traffic and responds with his own impersonation of victim.com, which uses a self-signed certificate. The "/attacker" page then again directs the user to a page at victim.com: https://victim.com/login. This time, the attacker allows the traffic to flow unmolested to the legitimate victim.com server. The browser now has two separate windows open on pages at victim.com. From the "/attacker" page, the attacker can script the authentic "/login" page. The user may believe that no attack is taking place, since the browser is presenting the "/login" page as safe and fully authenticated.

This attack is similar to those described by Collin Jackson and Adam Barth in their paper "Beware of Finer-Grained Origins" <http://crypto.stanford.edu/websec/origins/fgo.pdf>. The browser only enforces a boundary delimited by the hostname, port and scheme. The kind of certificate presented, or our rec's concept of TLS-protection level, is not reflected in the cross-frame scripting policy, and so is called a "finer grained origin", which is vulnerable to attack.

We might be able to fix this problem by requiring the browser to always present the lowest-common denominator TLS-protection level of any window that can script the active window.

--Tyler

Received on Tuesday, 2 September 2008 17:49:36 UTC