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.
14 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.
18
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