table 2: frame navigation policies deployed in existing browsers prior to our work.
ie 6 (Default) ie 6 (Optional) ie 7 (Default) ie 7 (Optional)
Permissive Child Descendant Permissive
most compatible) policy that prevents the attacker from
overwriting screen real estate “belonging” to another origin.
Although the child policy is stricter than the descendant
policy, the added strictness does not provide a significant
security benefit because the attacker can simulate the visual
effects of navigating a grandchild frame by drawing over
the region of the screen occupied by the grandchild frame.
The child policy’s added strictness does, however, reduce
the policy’s compatibility with existing sites, discouraging
browser vendors from deploying the child policy.
Maximizing the compatibility of the descendant policy
requires taking the browser’s scripting policy into account.
Consider one site that embeds two child frames from a second origin. Should one of those child frames be permitted
to navigate its sibling? Strictly construed, the descendant
policy forbids this navigation because the target frame is a
sibling, not a descendant. However, this navigation should
be allowed because an attacker can perform the navigation
by injecting a script into the sibling frame that causes the
frame to navigate itself. The browser lets the attacker inject
this script because the two frames are from the same origin.
More generally, the browser can maximize the compatibility
of the descendant policy by recognizing origin propagation
and letting an active frame navigate a target frame if the target frame is the descendant of a frame in the same origin as
the active frame. Defined in this way, the frame navigation
policy avoids creating a suborigin privilege.
11 This added permissiveness does not sacrifice security because an attacker
can perform the same navigations indirectly, but the refined
policy is more convenient for honest Web developers.
We collaborated with the HTML 5 working group9 and
standardized the descendant policy in the HTML 5 specification. The descendant policy has now been adopted by
Internet Explorer 7, Firefox 3, Safari 3. 1, and Google Chrome.
We also reported a vulnerability in Flash Player that could be
used to bypass Internet Explorer 7’s frame navigation policy.
Adobe fixed this vulnerability in a security update.
4. fRame COmmuniCatiOn
Unlike simple aggregators and advertisements, sophisticated mashups comprise gadgets that communicate with
each other and with their integrator. For example, Yelp
integrates the Google Maps gadget, illustrating the need
for secure interframe communication in real deployments.
Google provides two versions of its Maps gadget:
• Frame: In the frame version, the integrator embeds a
maps.google.com, in which Google displays
a map of the specified location. The user can interact
with the map, but the integrator cannot.
• script: In the script version, the integrator embeds
that the integrator can use to interact with the map, but
the script runs with all of the integrator’s privileges.
Yelp, a popular review Web site, uses the Google Maps gadget to display the locations of restaurants and other businesses. Yelp requires a high degree of interactivity with the
Maps gadget because it places markers on the map for each
restaurant and displays the restaurant’s review when the
user clicks on the marker. To deliver these advanced features, Yelp must use the script version of the Maps gadget,
but this design requires Yelp to trust Google Maps completely because Google’s script runs with Yelp’s privileges,
granting Google the ability to manipulate Yelp’s reviews and
steal Yelp’s customer’s information. Although Google might
be trustworthy, the script approach does not scale beyond
highly respected gadget providers. Secure interframe communication promises the best of both alternatives: sites
with functionality like Yelp can realize the interactivity of
the script version of Google Maps gadget while maintaining
the security of the frame version of the gadget.
4. 1. fragment identifier messaging
Although the browser’s scripting policy isolates frames from
different origins, clever mashup designers have discovered
an unintended channel between frames, fragment identifier messaging,
1, 21 which is regulated by the browser’s less-restrictive frame navigation policy. This “found” technology
lets mashup developers place each gadget in a separate
frame and rely on the browser’s security policy to prevent
malicious gadgets from attacking the integrator and honest
gadgets. We analyze fragment identifier messaging in use
prior to our analysis and propose improvements that have
since been adopted.
mechanism: Normally, when a frame is navigated to a new
URL, the browser requests the URL from the network and
replaces the frame’ document with the retrieved content.
However, if the new URL matches the old URL everywhere
except in the fragment (the part after the #), then the browser
does not reload the frame. If frames is currently located
frames.location = “ http://example.com/doc#msg”;
changes the frame’s location without reloading the frame
fragment by polling window.location.hash to see if the
fragment has changed. This technique can be used to send
messages between frames while avoiding network latency.
security Properties: The fragment identifier channel has
less-than-ideal security properties. The browser’s scripting