This policy prevents the cross-window attack because the Web attacker does not control a frame in a trusted window and, without a foothold in the window, the attacker cannot navigate the login frame. However, the window policy is insufficiently strict to protect users because the gadget attacker does have a foothold in a trusted window in a mashup. (Recall that, in a mashup, the integrator combines gadgets from different sources into a single experience.)

figure 2: Gadget hijacking. under the window policy, the attacker gadget can navigate other gadgets.

 

• aggregators: Gadget aggregators, such as iGoogle, My Yahoo! and Windows Live, provide one form of mashup. These sites let users customize their experience by including gadgets (such as stock tickers, weather predictions, and news feeds) on their home page. These sites put third-party gadgets in frames and rely on the browser to protect users from malicious gadgets.

• advertisements: Web advertising produces mashups that combine first-party content, such as news articles or sports statistics, with third-party advertisements. Most advertisements, including Google Ad Words, are contained in frames, both to prevent the advertisers (who provide the gadgets) from interfering with the publisher’s site and to prevent the publisher from using JavaScript to click on the advertisements.

(a) Before

We refer to pages with advertisements as simple mashups because the integrator and the gadgets do not communicate. Simple mashups rely on the browser to provide isolation but do not require interframe communication.

The windows policy offers no protection for mashups because the integrator’s window contains untrusted gadgets. A gadget attacker who supplies a malicious gadget does control a frame in the honest integrator’s window, giving the attacker the foothold required to mount a gadget hijacking attack. ¹⁴ A malicious gadget can navigate a target gadget to attacker.com and impersonates the gadget to the user. For example, iGoogle is vulnerable to gadget hijacking in browsers, such as Firefox 2, that implement the permissive or window policies; see Figure 2. Consider an iGoogle gadget that lets users access their Hotmail account. If the user is not logged into Hotmail, the gadget requests the user’s Hotmail password. A malicious gadget can replace the Hotmail gadget with and steal the user’s Hotmail password. As in the cross-window attack, the user is unable to distinguish the malicious password field from the honest password field.

(b) After

3. 4. stricter policies

Although browser vendors do not document their navigation policies, we reverse engineered the policies of existing browsers (see Table 2). In addition to the permissive and window policies, we found two other policies:

Descendant Policy
A frame can navigate only its descendants.

Child Policy
A frame can navigate only its direct children.

The Internet Explorer 6 team wanted to enable the child policy by default but shipped the permissive policy because the child policy was incompatible with a large number of Web sites. The Internet Explorer 7 team designed the descendant policy to balance the security requirement to defeat the cross-window attack with the compatibility requirement to support existing sites. ¹⁸

To select a frame navigation policy that provides the best trade-off between security and compatibility, we appeal to the principle of pixel delegation. When one frame embeds a child frame, the parent frame delegates a region of the screen to the child frame. The browser prevents the child frame from drawing outside of its bounding box but does allow the parent frame to draw over the child using the position: absolute style. Frame navigation attacks hinge on the attacker escalating his or her privileges and drawing on otherwise inaccessible regions of the screen. The descendant policy is the most permissive (and therefore