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”) evt.source.postMessage(secret, evt.origin);

 

We implemented this API change as patches for Firefox and Safari. Our proposal was accepted by the HTML 5 working group. ⁸ 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 SMash¹⁴ 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.

5. 2. safe subsets of htmL and Javascript 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” of HTML and JavaScript that prevents a malicious gadget 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

In Subspace, ¹³ we used a multilevel hierarchy of frames that coordinated their document.domain property to communicate directly in JavaScript. Similar to most frame-based mashups, the descendant frame navigation policy is required to prevent gadget hijacking.

5. 4. module tag

The proposed <module> tag² 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 attribute¹⁶ for frames. When set to restricted, the frame’s content cannot run JavaScript. Similarly, the proposed <jail> tag⁵ encloses untrusted content and prevents the jailed content from running JavaScript. Unfortunately, eliminating JavaScript prevents gadgets from offering interactive experiences.

55. 6. mashupOs

In MashupOS, ²² 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.

6. COnCLusiOn

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 Windows.Live.Channels, 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

15

adopted by Microsoft Windows Live, IBM Smash, ¹⁴ and the OpenAjax Alliance.

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.