extending the postMessage API with a second parameter:
targetOrigin. The browser will deliver the message only
if the frame’s current origin matches the specified target-
Origin. If the sender uses “ ” as the targetOrigin, the
browser will deliver the message to any origin. Using this
improved API, a frame can reply to a message using the following idiom:
if (evt.origin == “ https://gadget.com”)
We implemented this API change as patches for Firefox
and Safari. Our proposal was accepted by the HTML 5 working group.
8 The improved API is now available in Internet
Explorer 8, Firefox 3, Safari 4, and Google Chrome.
5. ReLateD WORk
5. 1. mitigations for gadget hijacking
SMash14 mitigates gadget hijacking (also known as “frame
phishing”) by carefully monitoring the frame hierarchy and
browser events for unexpected navigations. Although neither
the integrator nor the gadgets can prevent these navigations,
the mashup can alert the user and refuse to function if it detects
an illicit navigation. SMash waits 20s for a gadget to load before
assuming that the gadget has been hijacked. An attacker might
be able to fool the user into entering sensitive information during this interval, but using a shorter interval might cause users
with slow network connections to receive spurious warnings.
The descendant policy makes such mitigation unnecessary.
One way to sidestep the security issues of frame-based
mashups is to avoid using frames by combining the gadgets
and the integrator into a single document. This approach
forgoes the protections afforded by the browser’s security
policy and requires gadgets to be written in a “safe subset”
from attacking the integrator or other gadgets. Several open-source implementations (FBML, ADsafe, and Caja) are available. FBML is currently the most successful subsets and is
used by the Facebook Platform.
5. 3. subspace
13 we used a multilevel hierarchy of frames
that coordinated their
document.domain property to
required to prevent gadget hijacking.
5. 4. module tag
The proposed <module> tag2 is similar to the <iframe>
tag, but the module runs in an unprivileged security context,
without a principal, and the browser prevents the integrator from overlaying content on top of the module. Unlike
postMessage, the communication primitive used with
the <module> tag is explicitly unauthenticated because the
module lacks a principal.
90 COmmuniCatiOns Of the aCm | June2009 | VoL. 52 | no. 6
5. 5. security = restricted and jail
Internet Explorer supports a security attribute16 for
frames. When set to restricted, the frame’s content
tag5 encloses untrusted content and prevents the jailed
55. 6. mashupOs
22 we proposed new primitives both for isolation and communication. Our improvements to frame navigation policies and postMessage let developers realize
some of the benefits of MashupOS using existing browsers.
Web sites that combine content from multiple sources
can leverage browser frame isolation and interframe communication. Although the browser’s same-origin security
policy restricts direct access between frames, recent browsers have used differing policies to regulate when one frame
may navigate another. The original permissive frame navigation policy admits a number of attacks, and the subsequent
window navigation policy leaves mashups vulnerable to
similar attacks. The better descendant policy, which we collaborated with the HTML 5 working group to standardize,
balances security and compatibility and has been adopted
by Internet Explorer 7 (independently), Firefox 3, Safari 3. 1,
and Google Chrome.
In existing browsers, frame navigation can be used for interframe communication via a technique known as fragment
identifier messaging. If used directly, fragment identifier
messaging lacks authentication. We showed that the authentication protocols used by
SMash, and OpenAjax 1. 1 were vulnerable to attacks but can
be repaired in a manner analogous to Lowe’s variation of the
Needham–Schroeder protocol. This improvement has been
adopted by Microsoft Windows Live, IBM Smash,
14 and the
Originally, postMessage, another interframe communication channel, suffered the converse vulnerability: using
frame navigation, an attacker could breach confidentiality.
We propose extending the postMessage API to provide
confidentiality by letting the sender specify an intended
recipient. Our proposal has been adopted by the HTML
5 working group, Internet Explorer 8, Firefox 3, Safari 4,
Google Chrome, and Opera.
With these improvements, frames provide stronger isolation and better communication, becoming a more attractive feature for integrating third-party Web content. One
important area of future work is improving the usability of
the browser’s security user interface. For example, a gadget is permitted to navigate the top-level frame, redirecting
the user from the mashup to a site of the attacker’s choice.
Although the browser’s location bar makes this navigation
evident, many users ignore the location bar. Another area
for future work is improving isolation in the face of browser
implementation errors, which could let a gadget subvert the
browser’s security mechanisms.