Securing Frame Communication in Browsers

Adam BarthStanford University

abarth@cs.stanford.edu

Collin JacksonStanford University

collinj@cs.stanford.edu

John C. MitchellStanford University

mitchell@cs.stanford.edu

AbstractMany web sites embed third-party content in frames, re-lying on the browser’s security policy to protect themfrom malicious content. Frames, however, are often in-sufficient isolation primitives because most browsers letframed content manipulate other frames through naviga-tion. We evaluate existing frame navigation policies andadvocate a stricter policy, which we deploy in the open-source browsers. In addition to preventing undesirableinteractions, the browser’s strict isolation policy also hin-ders communication between cooperating frames. Weanalyze two techniques for inter-frame communication.The first method, fragment identifier messaging, pro-vides confidentiality without authentication, which werepair using concepts from a well-known network pro-tocol. The second method, postMessage, providesauthentication, but we discover an attack that breachesconfidentiality. We modify the postMessage API toprovide confidentiality and see our modifications stan-dardized and adopted in browser implementations.

1 Introduction

Web sites contain content from sources of varying trust-worthiness. For example, many web sites contain third-party advertising supplied by advertisement networks ortheir sub-syndicates [6]. Other common aggregationsof third-party content include Flickr albums [12], Face-book badges [9], and personalized home pages offeredby the three major web portals [15, 40, 28]. More ad-vanced uses of third-party components include Yelp’suse of Google Maps [14] to display restaurant locationsand the Windows Live Contacts gadget [27]. A website combining content from multiple sources is called amashup, with the party combining the content called theintegrator and integrated content called a gadget. In sim-ple mashups, the integrator does not intend to communi-cate with the gadgets and requires only that the browser

isolate frames. In more complex mashups, the integra-tor does intend to communicate with the gadgets and re-quires secure inter-frame communication.

In this paper, we study the contemporary web ver-sion of a recurring problem in computer systems: isolat-ing untrusted, or partially trusted, software componentswhile providing secure inter-component communication.Whenever a site integrates third-party content, such asan advertisement, a map, or a photo album, the site runsthe risk of incorporating malicious content. Without iso-lation, malicious content can compromise the confiden-tiality and integrity of the user’s session with the inte-grator. While the browser’s well-known “same-originpolicy” [34] restricts script running in one frame frommanipulating content in another frame, the browser usesa different policy to determine whether one frame is al-lowed to navigate (change the location of) another frame.Although restricting navigation is essential to providingisolation, navigation also enables one form of inter-framecommunication used in mashup frameworks from lead-ing companies. Furthermore, we show that an attackercan use frame navigation to attack another inter-framecommunication mechanism, postMessage.

Isolation. We examine the browser frame as an iso-lation primitive. Because frames can contain untrustedcontent, the browser’s security policy restricts frame in-teractions. Many browsers, however, insufficiently re-strict the ability of one frame to navigate another frameto a new location. These overly permissive frame nav-igation policies lead to a variety of attacks, which wedemonstrate against the Google AdSense login page andthe iGoogle gadget aggregator. To prevent these attacks,we propose tightening the browser’s frame navigationpolicy while maintaining compatibility with existing webcontent. We have collaborated with browser vendors todeploy this policy in Firefox 3 and Safari 3.1. As thepolicy is already implemented in Internet Explorer 7, thepolicy is now deployed in the three most-used browsers.

Confidentiality Authentication Network AnalogueFragment identifier channel X Public Key EncryptionpostMessage channel X Public Key SignaturespostMessage (our proposal) X X SSL/TLS

Table 1: Security properties of frame communication channels

Communication. With strong isolation, frames arelimited in their interactions, raising the issue of how iso-lated frames can cooperate as part of a mashup. Weanalyze two techniques for inter-frame communication:fragment identifier messaging and postMessage. Theresults of our analysis are summarized in Table 1.

• Fragment identifier messaging uses characteristicsof frame navigation to send messages betweenframes. As it was not designed for communica-tion, the channel has less-than-desirable securityproperties: messages are confidential but sendersare not authenticated. To understand these prop-erties, we draw an analogy between this commu-nication channel and a network channel in whichsenders encrypt their messages to their recipi-ent’s public key. For concreteness, we examinethe Microsoft.Live.Channels library [27],which uses fragment identifier messaging to letthe Windows Live Contacts gadget communicatewith its integrator. The protocol used by Win-dows Live is analogous to the Needham-Schroederpublic-key protocol [29]. We discover an attackon this protocol, related to Lowe’s anomaly in theNeedham-Schroeder protocol [23], in which a mali-cious gadget can impersonate the integrator to theContacts gadget. We suggested a solution basedon Lowe’s improvement to the Needham-Schroederprotocol [23], and Microsoft implemented and de-ployed our suggestion within days.

• postMessage is a new browser API designed forinter-frame communication [19]. postMessageis implemented in Opera, Internet Explorer 8, Fire-fox 3, and Safari. Although postMessage hasbeen deployed since 2005, we demonstrate an attackon the channel’s confidentiality using frame navi-gation. In light of this attack, the postMessagechannel provides authentication but lacks confiden-tiality, analogous to a channel in which senderscryptographically sign their messages. To se-cure the channel, we propose a change to thepostMessage API. We implemented our changein patches for Safari and Firefox. Our proposal hasbeen adopted by the HTML 5 working group, Inter-net Explorer 8, Firefox 3, and Safari.

Organization. The remainder of the paper is organizedas follows. Section 2 details the threat model for these at-tacks. Section 3 surveys existing frame navigation poli-cies and converges browsers on a secure policy. Sec-tion 4 analyzes two frame communication mechanisms,demonstrates attacks, and proposes defenses. Section 5describes related work. Section 6 concludes.

2 Threat Model

In this paper, we are concerned with securing in-browserinteractions from malicious attackers. We assume anhonest user employs a standard web browser to view con-tent from an honest web site. A malicious “web attacker”attempts to disrupt this interaction or steal sensitive infor-mation. Typically, a web attacker places malicious con-tent (e.g., JavaScript) in the user’s browser and modifiesthe state of the browser, interfering with the honest ses-sion. To study the browser’s security policy, which deter-mines the privileges of the attacker’s content, we definethe web attacker threat model below.

Web Attacker. A web attacker is a malicious princi-pal who owns one or more machines on the network. Inorder to study the security of browsers when renderingmalicious content, we assume that the browser gets andrenders content from the attacker’s web site.

• Network Abilities. The web attacker has no spe-cial network abilities. In particular, the web attackercan send and receive network messages only frommachines under his or her control, possibly actingas a client or server in network protocols of the at-tacker’s choice. Typically, the web attacker uses atleast one machine as an HTTP server, which werefer to for simplicity as attacker.com. Theweb attacker can obtain SSL certificates for do-mains he or she owns; certificate authorities suchas instantssl.com provide such certificates forfree. The web attacker’s network abilities are decid-edly weaker than the usual network attacker consid-ered in studies of network security because the webattacker can neither eavesdrop on messages sent toother recipients nor forge messages from other net-work locations. For example, a web attacker cannotact as a “man-in-the-middle.”

• Interaction with Client. We assume the honestuser views attacker.com in at least one browserwindow, thereby rendering the attacker’s content.We make this assumption because we believe thatan honest user’s interaction with an honest siteshould be secure even if the user separately vis-its a malicious site in a different browser window.We assume the web attacker is constrained by thebrowser’s security policy and does not employ abrowser exploit to circumvent the policy. The webattacker’s host privileges are decidedly weaker thanan attacker who can execute a arbitrary code on theuser’s machine with the user’s privileges. For exam-ple, a web attacker cannot install or run a system-wide key logger or botnet client.

Attacks accessible to a web attacker have significantpractical impact because the attacks can be mountedwithout any complex or unusual control of the network.In addition, web attacks can be carried out by a standardman-in-the-middle network attacker, provided the uservisits a single HTTP site, because a man-in-the-middlecan intercept HTTP requests and inject malicious contentinto the reply, simulating a reply from attacker.com.

There are several techniques an attacker can use todrive traffic to attacker.com. For example, an at-tacker can place web advertisements, display popularcontent indexed by search engines, or send bulk e-mail toattract users. Typically, simply viewing an attacker’s ad-vertisement lets the attacker mount a web-based attack.In a previous study [20], we purchased over 50,000 im-pressions for $30. During each of these impressions, auser’s browser rendered our content, giving us the accessrequired to mount a web attack.

We believe that a normal, but careful, web user whoreads news and conducts banking, investment, and re-tail transactions, cannot effectively monitor or restrict theprovenience of all content rendered in his or her browser,especially in light of third-party advertisements. In otherwords, we believe that the web attacker threat model is anaccurate representation of normal web behavior, appro-priate for security analysis of browser security, and notan assumption that users promiscuously visit all possiblebad sites in order to tempt fate.

Gadget Attacker. A gadget attacker is a web attackerwith one additional ability: the integrator embeds a gad-get of the attacker’s choice. This assumption lets us ac-curately evaluate mashup isolation and communicationprotocols because the purpose of these protocols is to letan integrator embed untrusted gadgets safely. In practice,a gadget attacker can either wait for the user to visit theintegrator or can redirect the user to the integrator’s website from attacker.com.

Out-of-Scope Threats. Although phishing [11, 7] canbe described informally as a “web attack,” the webattacker defined above does not attempt to fool theuser by choosing a confusing domain name (such asbankofthevvest.com) or using other social engi-neering. In particular, we do not assume that a usertreats attacker.com as if it were a site other thanattacker.com. The attacks presented in this paperare “pixel-perfect” in the sense that the browser providesthe user no indication whatsoever that an attack is under-way. The attacks do not display deceptive images overthe browser security indicators nor do they spoof the lo-cation bar and or the lock icon. In this paper, we do notconsider cross-site scripting attacks, in which an attackerexploits a bug in an honest principal’s web site to injectmalicious content into another security origin. None ofthe attacks described in this paper rely on the attackerinjecting content into another principal’s security origin.Instead, we focus on privileges the browser itself affordsthe attacker to interact with honest sites.

3 Frame Isolation

Netscape Navigator 2.0 introduced the HTML <frame>element, which allows web authors to delegate a portionof their document’s screen real estate to another doc-ument. These frames can be navigated independentlyof the rest of the main content frame and can, them-selves, contain frames, further delegating screen real es-tate and creating a frame hierarchy. Most modern framesare embedded using the more-flexible <iframe> ele-ment, introduced in Internet Explorer 3.0. In this paper,we use the term frame to refer to both <frame> and<iframe> elements. The main, or top-level, frame ofa browser window displays its location in the browser’slocation bar. Subframes are often indistinguishable fromother parts of a page, and the browser does not displaytheir location in its user interface. Browsers decorate awindow with a lock icon only if every frame containedin the window was retrieved over HTTPS but do not re-quire the frames to be served from the same host. For ex-ample, if https://bank.com/ embeds a frame fromhttps://attacker.com/, the browser will deco-rate the window with a lock icon.

Organization. Section 3.1 reviews browser securitypolicies. Section 3.2 describes cross-window framenavigation attacks and defenses. Section 3.3 detailssame-window attacks that are not impeded by the cross-window defenses. Section 3.4 analyzes stricter naviga-tion policies and advocates the “descendant policy.” Sec-tion 3.5 documents our implementation and deploymentof the descendant policy in major browsers.

3.1 Background

Scripting Policy. Most web security is focused on thebrowser’s scripting policy, which answers the question“when is script in one frame permitted to manipulate thecontents of another frame?” The scripting policy is themost important browser security policy because the abil-ity to script another frame is the ability to control itsappearance and behavior completely. For example, ifotherWindow is another window’s frame,

var stolenPassword =otherWindow.document.forms[0].password.value;

attempts to steal the user’s password in the other win-dow. Modern web browsers permit one frame to readand write all the DOM properties of another frame onlywhen their content was retrieved from the same ori-gin, i.e. when the scheme, host, and port number oftheir locations match. If the content of otherWindowwas retrieved from a different origin, the browser’s se-curity policy will prevent this script from accessingotherWindow.document.

Navigation Policy. Every browser must answer thequestion “when is one frame permitted to navigate an-other frame?” Prior to 1999, all web browsers imple-mented a permissive policy:

Permissive PolicyA frame can navigate any other frame.

For example, if otherWindow includes a frame,

otherWindow.frames[0].location ="https://attacker.com/";

navigates the frame to https://attacker.com/.This has the effect of replacing the frame’s docu-ment with content retrieved from that URL. Underthe permissive policy, this navigation succeeds even ifotherWindow contains content from a different secu-rity origin. There are a number of other idioms for navi-gating frames, including

window.open("https://attacker.com/","frameName");

which requests that the browser search for a frame namedframeName and navigate the frame to the specifiedURL. Frame names exist in a global name space and arenot restricted to a single security origin.

Top-level Frames. Top-level frames are often exemptfrom the restrictions imposed by the browser’s framenavigation policy. Top-level frames are less vulnerableto frame navigation attacks because the browser displaystheir location in the location bar. Internet Explorer andSafari do not restrict the navigation of top-level framesat all. Firefox restricts the navigation of top-level framesbased on their openers, but this restriction can be circum-vented [2]. Opera implements a number of restrictionson the navigation of top-level frames based on the cur-rent location of the frame.

3.2 Cross-Window AttacksIn 1999, Georgi Guninski discovered that the permis-sive frame navigation policy admits serious attacks [16].Guninski discovered that, at the time, the passwordfield on the CitiBank login page was contained withina frame. Because the permissive frame navigation policylets any frame navigate any other frame, a web attackercan navigate the password frame on CitiBank’s pageto https://attacker.com/, replacing the framewith identical-looking content that sends the user’s pass-word to attacker.com. In the modern web, thiscross-window attack might proceed as follows:

1. The user reads a popular blog that displays a Flashadvertisement provided by attacker.com.

2. The user opens a new window to bank.com,which displays its password field in a frame.

3. The malicious advertisement navigates the pass-word frame to https://attacker.com/. Thelocation bar still reads bank.com and the lock iconis not removed.

4. The user enters his or her password, which is thensubmitted to attacker.com.

Of the browsers in heavy use today, Internet Explorer 6and Safari 3 both implement the permissive policy. In-ternet Explorer 7 and Firefox 2 implement stricter poli-cies (described in subsequent sections). However, FlashPlayer can be used to circumvent the stricter navigationpolicy of Internet Explorer 7, effectively reducing thepolicy to “permissive.” Many web sites are vulnerable tothis attack, including Google AdSense, which displaysits password field inside a frame; see Figure 1.

Window Policy. In response to Guninski’s report,Mozilla implemented a stricter policy in 2001:

Window PolicyA frame can navigate only frames in its window.

Figure 1: Cross-Window Attack: The attacker controls the password field because it is contained within a frame.

This policy prevents the cross-window attack because theweb attacker does not control a frame in the same win-dow as the CitiBank or the Google AdSense login page.Without a foothold in the window, the attacker cannotnavigate the login frame to attacker.com.

3.3 Same-Window AttacksThe window frame navigation policy is neither univer-sally deployed nor sufficiently strict to protect users onthe modern web because mashups violate its implicit se-curity assumption that an honest principal will not embeda frame to a dishonest principal.

Mashups. A mashup combines content from multiplesources to create a single user experience. The partycombining the content is called the integrator and theintegrated content is called a gadget.

• Aggregators. Gadget aggregators, such asiGoogle [15], My Yahoo [40], and Win-dows Live [28], are one form of mashup. Thesesites let users customize their experience by se-lecting gadgets (such as stock tickers, weatherpredictions, news feeds, etc) to include on theirhome page. Third parties are encouraged to developgadgets for the aggregator. These mashups embedthe selected gadgets in a frame and rely on thebrowser’s frame isolation to protect users frommalicious gadgets.

• Advertisements. Web advertising is a simple formof mashup, combining first-party content, such asnews articles or sports statistics, with third-party ad-vertisements. Typically, the publisher (the integra-tor) delegates a portion of its screen real estate to anadvertisement network, such as Google, Yahoo, or

Microsoft, in exchange for money. Most advertise-ments, including Google AdWords, are contained inframes, both to prevent the advertisers (who providethe gadgets) from interfering with the publisher’ssite and to prevent prevent the publisher from usingJavaScript to click on the advertisements.

We refer to aggregators and advertisements as simplemashups because these mashups do not involve commu-nication between the gadgets and the integrator. Simplemashups rely on the browser to provide isolation but donot require inter-frame communication.

Gadget Hijacking Attacks. Mashups invalidate animplicit assumption of the window policy, that an hon-est principal will not embed a frame to a dishonest prin-cipal. A gadget attacker, however, does control a frameembedded by the honest integrator, giving the attackerthe foothold required to mount a gadget hijacking at-tack [22]. In such an attack, a malicious gadget navi-gates a target gadget to attacker.com and imperson-ates the gadget to the user.

• Aggregator Vulnerabilities. iGoogle is vulnerableto gadget hijacking in browsers, such as Firefox 2,that implement the permissive or window policies;see Figure 2. Consider, for example, one popu-lar iGoogle gadget that lets users access their Hot-mail inbox. (This gadget is neither provided norendorsed by Microsoft.) If the user is not loggedinto Hotmail, the gadget requests the user’s Hotmailpassword. A malicious gadget can replace the Hot-mail gadget with content that asks the user for his orher Hotmail password. As in the cross-window at-tack, the user is unable to distinguish the maliciouspassword field from the honest password field.

(a) Before (b) After

Figure 2: Gadget Hijacking Attack. Under the window policy, the attacker gadget can navigate the other gadgets.

• Advertisement Vulnerabilities. Although text ad-vertisements often do not contain active content(e.g., JavaScript), other forms of advertising, suchas Flash advertisements, do contain active content.An attacker who provides such an advertisementcan steal advertising impressions allotted to otheradvertisers via gadget hijacking. A malicious ad-vertisement can traverse the page’s frame hierar-chy and navigate frames containing other advertise-ments to attacker.com, replacing the existingcontent with the attacker’s advertisement.

3.4 Stricter PoliciesAlthough browser vendors do not document their naviga-tion policies, we were able to reverse engineered the nav-igation policies of existing browsers, and we confirmedour understanding with the browsers’ developers. Theexisting policies are shown in Table 2. In addition tothe permissive and window policies described above, wediscovered two other frame navigation policies:

Descendant PolicyA frame can navigate only its descendants.

Child PolicyA frame can navigate only its direct children.

The Internet Explorer 6 team wanted to enable the childpolicy by default, but shipped the permissive policy be-cause the child policy was incompatible with a largenumber of web sites. The Internet Explorer 7 team de-signed the descendant policy to balance the security re-quirement to defeat the cross-window attack with thecompatibility requirement to support existing sites [33].

Pixel Delegation. The descendant policy provides themost attractive trade-off between security and compat-ibility because it is the least restrictive policy that re-spects pixel delegation. When one frame embeds anotherframe, the parent frame delegates a region of the screento the child frame. The browser prevents the child framefrom drawing outside of its bounding box but does al-low the parent frame to draw over the child using theposition: absolute style. The descendant policypermits a frame to navigate a target frame precisely whenthe frame could overwrite the screen real estate of the tar-get frame. Although the child policy is stricter than thedescendant policy, the additional strictness does not pre-vent many additional attacks because a frame can sim-ulate the visual effects of navigating a grandchild frameby drawing over the region of the screen occupied bythe grandchild frame. The child policy’s added strictnessdoes, however, reduce the policy’s compatibility with ex-isting sites, discouraging browser vendors from deploy-ing the child policy.

Origin Propagation. A strict interpretation of the de-scendant policy prevents a frame from navigating its sib-lings, even if the frame is from the same security originas its parent. In this situation, the frame can navigate itssibling indirectly by injecting script into its parent, whichcan then navigate the sibling because the sibling is a de-scendant of the parent frame. In general, browsers shoulddecide whether or not to permit a navigation based on theactive frame’s security origin. Browsers should let an ac-tive frame navigate a target frame if there exists a framein the same security origin as the active frame that hasthe target frame as a descendant. By recognizing this ori-gin propagation, browsers can achieve a better trade-off

between security and compatibly. These additional navi-gations do not sacrifice security because an attacker canperform the navigations indirectly, but allowing them ismore convenient for honest web developers.

3.5 DeploymentWe collaborated with the HTML 5 working group [18]and browser vendors to deploy the descendant policy inseveral browsers:

• Safari. We implemented the descendant policy asa patch for Safari. Apple accepted our patch anddeployed the descendant policy to Mac OS X andWindows Safari users as a security update [30]. Ap-ple also deployed our patch to all iPhone and iPodtouch users.

• Firefox. We implemented the descendant policy asa patch for Firefox. Before accepting our patch,Mozilla requested tests for all their previous framenavigation regressions. We provided them with ap-proximately 1000 lines of regression tests for theirautomatic test harness, covering the frame naviga-tion security vulnerabilities from the past ten years.Mozilla accepted our patch and deployed the de-scendant policy in Firefox 3 [1].

• Flash. We reported to Adobe that Flash Player by-passes the descendant policy in Internet Explorer 7.Adobe agreed to ship a patch to all Internet Explorerusers in their next security update.

• Opera. We notified Opera Software about inconsis-tencies in Opera’s child policy that can be used ingadget hijacking attacks. They plan to fix these vul-nerabilities in the upcoming release of Opera 9.5,and are evaluating the compatibility benefits ofadopting the descendant policy [35].

4 Frame Communication

Over the past few years, web developers have built so-phisticated mashups that, unlike simple aggregators andadvertisements, are comprised of gadgets that commu-nicate with each other and with their integrator. Yelp,which integrates the Google Maps gadget, motivates theneed for secure inter-frame communication by illustrat-ing how communicating gadgets are used in real de-ployments. Sections 4.1 and 4.2 analyze and improvefragment-identifier messaging and postMessage.

Google Maps. One popular gadget is the Google MapsAPI [14]. Google provides two mechanisms for integrat-ing Google Maps:

• Frame. In the frame version of the gadget, the in-tegrator embeds a frame to maps.google.com,which Google fills with a map centered at the speci-fied location. The user can interact with map, butthe integrator is oblivious to this interaction andcannot interact with the map directly.

• Script. In the script version of the gadget, theintegrator embeds a <script> tag that executesJavaScript from maps.google.com. This scriptcreates a rich JavaScript API the integrator can useto interact with the map, but the script runs with allof the integrator’s privileges.

Yelp. Yelp is a popular review web site that uses theGoogle Maps gadget to display the locations of restau-rants and other businesses it reviews. Yelp requires ahigh degree of interactivity with the Maps gadget be-cause it places markers on the map for each restaurantand displays the restaurant’s review when the user clickson the marker. In order to deliver these advanced fea-tures, Yelp must use the script version of the Maps gad-get. This design requires Yelp to trust Google Maps com-pletely because Google’s script runs with Yelp’s priv-ileges in the user’s browser, granting Google the abil-ity to manipulate Yelp’s reviews and steal Yelp’s cus-tomer’s information. Although Google might be trust-worthy, the script approach does not scale beyond highlyrespected gadget providers. Secure inter-frame commu-nication provides the best of both alternatives: Yelp (andsimilar sites) can realize the interactivity of the script ver-sion of Google Maps gadget while maintaining the secu-rity of the frame version of the gadget.

4.1 The Fragment Identifier ChannelAlthough the browser’s scripting policy isolates framesfrom different security origins, clever mashup designershave discovered an unintended channel between frames:the fragment identifier channel [3, 36]. This channel isregulated by the browser’s less-restrictive frame naviga-tion policy. This “found” technology lets mashup devel-opers place each gadget in a separate frame and rely onthe browser’s security policy to prevent malicious gad-gets from attacking the integrator and honest gadgets.

Mechanism. Normally, when a frame is navigated toa new URL, the browser retrieves the URL from thenetwork and replaces the frame’s document with theretrieved content. However, if the new URL differ-ent from the old URL only in the fragment (the por-tion after the #), then the browser does not reloadthe frame. If frames[0] is currently located athttp://example.com/doc,

IE 6 (default) IE 6 (optional) IE 7 (default) IE 7 (optional) Firefox 2 Safari 3 Opera 9Permissive Child Descendant Permissive Window Permissive Child

Table 2: Frame navigation policies deployed in existing browsers.

frames[0].location ="http://example.com/doc#message";

changes the frame’s location without reloading the frameor destroying its JavaScript context. The frame can ob-serve the value of the fragment by periodically pollingwindow.location.hash to see if the fragmentidentifier has changed. This technique can be used tosend short string messages entirely within the browser,avoiding network latency. However, the communicationchannel is somewhat unreliable because, if two naviga-tions occur between polls, the first message will be lost.

Security Properties. Because it was “found” and notdesigned, the fragment identifier channel has less-than-ideal security properties. The browser’s scripting policyprevents security origins other than the one preceding the# from eavesdropping on messages because they are un-able to read the frame’s location (even though the nav-igation policy permits them to write to the frame’s lo-cation). Browsers also prevent arbitrary security originsfrom tampering with portions of messages. Other secu-rity origins can, however, overwrite the fragment iden-tifier in its entirety, leaving the recipient to guess thesender of each message.

To understand these security properties, we developan analogy with well-known properties of network chan-nels. We view the browser as guaranteeing that the frag-ment identifier channel has confidentiality: a messagecan be read only by its intended recipient. The fragmentidentifier channel fails to be a secure channel because itlacks authentication, the ability of the recipient to un-ambiguously determine the sender of a message. Thechannel also fails to be reliable because messages mightnot be delivered, and the attacker might be able to replayprevious messages using the browser’s history API.

The security properties of the fragment identifier chan-nel are analogous to a channel on an untrusted networksecured by a public-key cryptosystem in which eachmessage is encrypted with the public key of its intendedrecipient. In both cases, if Alice sends a message to Bob,no one except Bob learns the contents of the message(unless Bob forwards the message). In both settings, thechannel does not provide a reliable procedure for deter-mining who sent a given message. There are two inter-esting differences between the fragment identifier chan-nel and the public-key channel:

1. The public-key channel is susceptible to traffic anal-ysis, but an attacker cannot determine the length ofa message sent over the fragment identifier channel.An attacker can extract timing information by fre-quently polling the browser’s clock, but obtaining ahigh-resolution timing signal significantly degradesthe browser’s performance.

2. The fragment identifier channel is constrained bythe browser’s frame navigation policy. In principle,this could be used to construct protocols secure forthe fragment identifier channel that are insecure forthe public-key channel (by preventing the attackerfrom navigating the recipient), but in practice thisrestriction has not prevented us from constructingattacks on existing protocol implementations.

Despite these differences, we find the network analogyuseful in analyzing inter-frame communication.

Windows Live Channels. Microsoft uses the frag-ment identifier channel in its Windows Live plat-form library to implement a higher-level channel API,Microsoft.Live.Channels [36]. The WindowsLive Contacts gadget uses this API to communicate withits integrator. The integrator can instruct the gadget toadd or remove contacts from the user’s contacts list, andthe gadget can send the integrator details about the user’scontacts. Whenever the integrator asks the gadget to per-form a sensitive action, the gadget asks the user to con-firm the operation and displays the integrator’s host nameto aid the user in making trust decisions.Microsoft.Live.Channels attempts to build a

secure channel over the fragment identifier channel. Byreverse engineering the implementation, we determinedthat it uses two sessions of the following protocol (one ineach direction) to establish a secure channel:

A→ B : NA, URIAB → A : NA, NB

A→ B : NB , Message1

In this notation, A and B are frames, NA and NB arefresh nonces (numbers chosen at random during eachrun of the protocol), and URIA is the location of A’sframe. Under the network analogy described above,this protocol is analogous to a variant of the classicNeedham-Schroeder key-establishment protocol [29].

Figure 3: Lowe Anomaly: This Windows Live Contactsgadget received a message that appeared to come fromintegrator.com, but in reality the request was madeby attacker.com.

The Needham-Schroeder protocol was designed to estab-lish a shared secret between two parties over an insecurechannel. In the Needham-Schroeder protocol, each mes-sage is encrypted with the public key of its intended re-cipient. The Windows Live protocol does not employ en-cryption because the fragment identifier channel alreadyprovides the required confidentiality.

The Needham-Schroeder protocol has a well-knownanomaly, due to Lowe [23], which leads to an attack inthe browser setting. In the Lowe scenario, an honest prin-cipal, Alice, initiates the protocol with a dishonest party,Eve. Eve then convinces honest Bob that she is Alice. Inorder to exploit the Lowe anomaly, an honest principalmust be willing to initiate the protocol with a dishonestprincipal. This requirement is met in mashups becausethe integrator initiates the protocol with the gadget at-tacker’s gadget in order to establish a channel. The Loweanomaly can be exploited to impersonate the integrator tothe Windows Live Contacts gadget as follows:

Integrator→ Attacker : NI , URIIAttacker→ Gadget : NI , URII

Gadget→ Integrator : NI , NG

Integrator→ Attacker : NG, Message1

After these four messages, the attacker possesses NI andNG and can impersonate the integrator to the gadget.We have successfully implemented this attack against theWindows Live Contacts gadget. The issue is easily ob-servable for the Contacts gadget because the gadget dis-plays the integrator’s host name to the user in its securityuser interface; see Figure 3.

SMash and OpenAjax 1.1. A recent paper [22] fromIBM proposed another protocol for establishing a securechannel over the fragment identifier channel. They de-scribe their protocol as follows:

The SMash library in the mashup applica-tion creates the secret, an unguessable randomvalue. When creating the component, it in-cludes the secret in the fragment of the com-ponent URL. When the component creates thetunnel iframe it passes the secret in the samemanner.

The SMash developers have contributed their code to theOpenAjax project, which plans to include their fragmentidentifier protocol in version 1.1. The SMash protocolcan be understood as follows:

A→ B : N, URIAB → A : N

A→ B : N, Message1

This protocol admits the following simple attack:

Attacker→ Gadget : N, URIIGadget→ Integrator : N

Attacker→ Gadget : N, Message

We have confirmed this attack by implementing the at-tack against the SMash implementation. Additionally,the attacker is able to conduct this attack covertly byblocking the message from the gadget to the integratorbecause the message waits for the load event to fire.

Secure Fragment Messaging. The fragment identifierchannel can be secured using a variant of the Needham-Schroeder-Lowe protocol [23]. The main idea in Lowe’simprovement of the Needham-Schroeder protocol is thatthe responder must include his identity in the secondmessage of the protocol, letting the honest initiator deter-mine that an attack is in progress and abort the protocol.

A→ B : NA, URIAB → A : NA, NB , URIBA→ B : NB

. . .

A→ B : NA, NB , Messagei

B → A : NA, NB , Messagej

We contacted Microsoft, IBM, and the OpenA-JAX Alliance about the vulnerabilities in their frag-ment identifier messaging protocols and suggestedthe above protocol improvement. Microsoft adoptedour suggestions and deployed a patched version of

Gadgettop.postMessage(msg)

source.postMessage(secret)

Aacker

Aacker

Integrator

Gadget

postMessage(secret)

Aacker

Integrator

(a) Integrator sends secret messages to child

Gadgettop.postMessage(msg)

source.postMessage(secret)

Aacker

Aacker

Integrator

GadgetAacker

postMessage(secret)

Aacker

Integrator

(b) Attacker hijacks integrator’s child

Figure 4: Recursive Mashup Attack

Microsoft.Live.Channels and of the WindowsLive Contacts gadget. IBM adopted our suggestions andrevised their SMash paper. The OpenAJAX Allianceadopted our suggestions and updated their codebase. Allthree now use the above protocol to establish a securechannel using fragment identifiers.

4.2 The postMessage ChannelHTML 5 [19] specifies a new browser API for asyn-chronous communication between frames. Unlike thefragment identifier channel, the postMessage chan-nel was designed for cross-site communication. ThepostMessage API was originally implemented inOpera 8 and is now supported by Internet Explorer 8,Firefox 3 [37], and Safari [24].

Mechanism. To send a message to another frame, thesender calls the postMessage method:

frames[0].postMessage("Hello world.");

The browser then generates a message event in therecipient’s frame that contains the message, the ori-gin (scheme, port, and domain) of the sender, and aJavaScript pointer to the frame that sent the message.

Security Properties. The postMessage channelguarantees authentication, messages accurately identifytheir senders, but the channel lacks confidentiality. Thus,postMessage has almost the “opposite” security prop-erties as the fragment identifier channel. Where the frag-ment identifier channel has confidentiality without au-thentication, the postMessage channel has authenti-cation without confidentiality. The security propertiesof the postMessage channel are analogous to a chan-nel on a untrusted network secured by an existentiallyunforgeable signature scheme. In both cases, if Alicesends a message to Bob, Bob can determine unambigu-ously that Alice sent the message. With postMessage,

the origin property accurately identifies the sender;with cryptographic signatures, verifying the signatureon a message accurately identifies the signer of themessage. One difference between the channels is thatcryptographic signatures can be easily replayed, but thepostMessage channel is resistant to replay attacks. Insome cases, however, an attacker might be able to mounta replay attack by reloading honest frames.

Attacks. Although postMessage is widely believedto provide a secure channel between frames, we showan attack on the confidentiality of the channel. A mes-sage sent with postMessage is directed at a frame, butif the attacker navigates that frame to attacker.combefore the message event is generated, the attacker willreceive the message instead of the intended recipient.

• Recursive Mashup Attack. Suppose, for exam-ple, that an integrator embeds a frame to a gadgetand then calls postMessage on that frame. Theattacker can load the integrator inside a frame andcarry out an attack without violating the descendantframe navigation policy. After the attacker loads theintegrator inside a frame, the attacker navigates thegadget frame to attacker.com. Then, when theintegrator calls postMessage on the “gadget’s”frame, the browser delivers the message to the at-tacker whose content now occupies the “gadget’s”frame; see Figure 4. The integrator can prevent thisattack by “frame busting,” i.e., by refusing to renderthe mashup if top !== self, indicating that theintegrator is contained in a frame.

• Reply Attack. Another postMessage idiom isalso vulnerable to interception, even under the childframe navigation policy:

window.onmessage = function(e) {if (e.origin == "https://b.com")

e.source.postMessage(secret);};

Gadgettop.postMessage(msg)

Aacker

Integrator

(a) Gadget requests secret from integrator

Gadgettop.postMessage(msg)

e.source.postMessage(secret)

Aacker

Aacker

Integrator

(b) Integrator’s reply is delivered to attacker

Figure 5: Reply Attack

The source attribute of the MessageEvent isa JavaScript reference to the frame that sent themessage. It is tempting to conclude that the re-ply will be sent to https://b.com. How-ever, an attacker might be able to intercept themessage. Suppose that the honest gadget callstop.postMessage("Hello"). The gadgetattacker can intercept the message by embeddingthe honest gadget in a frame, as depicted in Fig-ure 5. After the gadget posts its message to theintegrator, the attacker navigates the honest gad-get to https://attacker.com. (This naviga-tion is permitted under both the child and descen-dant frame navigation policies.) When the integra-tor replies to the source of the message, the mes-sage will be delivered to the attacker instead of tothe honest gadget.

Securing postMessage. It might be feasible for sitesto build a secure channel using postMessage as anunderlying communication primitive, but we would pre-fer that postMessage provide a secure channel na-tively. In MashupOS [39], we proposed a new browserAPI, CommRequest, to send messages between ori-gins. When sending a message using CommRequest,the sender addresses the message to a principal:

var req = new CommRequest();req.open("INVOKE",

"local:https://b.com//inc");req.send("Hello");

Using this interface, CommRequest protects the confi-dentiality of messages because the CommServer willdeliver messages only to the specified principal. Al-though CommRequest provides adequate security, thepostMessage API is further along in the standard-ization and deployment process. We therefore proposeextending the postMessage API to provide the addi-tional security benefits of CommRequest by including

a second parameter: the origin of the intended recipi-ent. If the sender specifies a target origin, the browserwill deliver the message to the targeted frame only if thatframe’s current security origin matches the argument.The browser is free to deliver the message to any prin-cipal if the sender specifies a target origin of *. Usingthis improved API, a frame can reply to a message usingthe following idiom:

window.onmessage = function(e) {if (e.origin == "https://b.com")e.source.postMessage(secret,

e.origin);};

As shown in this example use, the API uses the sameorigin syntax for both sending and receiving messages.The scheme is included in the origin for those develop-ers who wish to defend against active network attackersby distinguishing between HTTP and HTTPS. We imple-mented this API change as a patch for Safari and a patchfor Firefox. Our proposal was accepted by the HTML 5working group [17]. The new API is now included inFirefox 3 [38], Safari [32], and Internet Explorer 8 [25].

5 Related Work

Mitigations for Gadget Hijacking. SMash [22] mit-igates gadget hijacking (which the authors refer to as“frame phishing”) without modifying the browser bycarefully monitoring the frame hierarchy and browserevents for evidence of unexpected navigation. Neitherthe integrator nor the gadget can prevent these naviga-tions, but the mashup can alert the user and refuse tofunction if it detects an illicit navigation. This approachlets an attacker mount a denial-of-service attack againstthe mashup, but a web attacker can already mount adenial-of-service attack against the entire browser by is-suing a blocking XMLHttpRequest or entering an in-finite loop.

Unfortunately, this approach can lead to false posi-tives. SMash waits 20 seconds for a gadget to load beforeassuming that the gadget has been hijacked and warningthe user. An attacker might be able to fool the user intoentering sensitive information during this time interval.Using a shorter time interval might cause users with slownetwork connections to receive warnings even though noattack is in progress. We expect that the deployment ofthe descendant policy will obviate the need for server-enforced gadget hijacking mitigations.

Safe Subsets of HTML and JavaScript. One way tosidestep the security issues of frame-based mashups is toavoid using frames entirely and render the gadgets to-gether with the integrator in a single document. Thisapproach forgoes the protections of the browser’s se-curity policy because all the gadgets and the integra-tor share a single browser security context. To main-tain security, this approach requires gadgets to be writ-ten in a “safe subset” of HTML and JavaScript that pre-vents a malicious gadget from attacking the integrator orother gadgets. Analyzing the security and usability ofthese subsets is an active area of research. Several open-source [13, 4] and closed-source [31, 10] implementa-tions are available. FBML [10] is currently the most suc-cessful of these subsets and is used by millions of usersas the foundation of the Facebook Platform.

Writing programs in one of these safe subsets is oftenawkward because the language is highly constrained toavoid potentially dangerous features. To improve usabil-ity, the safe subsets are often accompanied by a com-piler that transforms untrusted HTML and JavaScriptinto the subset, possibly at the cost of performance.These safe subsets will become easier to use over timeas these compilers become more sophisticated and morelibraries become available, but with the deployment ofpostMessage and the descendant policy, we expectthat frame-based mashup designs will continue to findwide use as well.

Other Frame Isolation Proposals. There are severalother proposals for frame isolation and communication:

• Subspace. In Subspace [21], we used a multi-level hierarchy of frames that coordinated theirdocument.domain property to communicate di-rectly in JavaScript. Similar to most frame-basedmashups, the descendant frame navigation policy isrequired to prevent gadget hijacking.

• Module Tag. The proposed <module> tag [5]is similar to an <iframe> tag, but the moduleruns in an unprivileged security context, without aprincipal, and the browser prevents the integrator

from overlaying content on top of the module. Un-like postMessage, the communication primitiveused with the module tag is intentionally unauthen-ticated: it does not identify the sender of a message.It is unknown whether navigation can be used to in-tercept messages as there are no implementations ofthe <module> tag.

• Security=Restricted and Jail. Internet Ex-plorer supports a security attribute [26] offrames that can be set to restricted. Withsecurity="restricted", the frame’s con-tent cannot run JavaScript. Similarly, the pro-posed <jail> tag [8] encloses untrusted contentand prevents the sandboxed content from runningJavaScript. However, eliminating JavaScript pre-vents gadgets from offering interactive experiences.

• MashupOS. Our MashupOS proposal [39] includesnew primitives for isolating web content while al-lowing secure communication. Our improvementsto postMessage and frame navigation policiesallow web authors to obtain some of the benefits ofMashupOS using existing web APIs.

6 Conclusions

Web browsers provide a platform for web applica-tions. These applications rely on the browser to isolateframes from different security origins and to provide se-cure inter-frame communication. To provide isolation,browsers implement a number of security policies, in-cluding a frame navigation policy. The original framenavigation policy, the permissive policy, admits a numberof attacks. The modern frame navigation policy, the de-scendant policy, prevents these attacks by permitting oneframe to navigate another only if the frame could drawover the other frame’s region of the screen. The descen-dant policy provides an attractive trade-off between secu-rity and compatibility, is deployed in the major browsers,and has been standardized in HTML 5.

In existing browsers, frame navigation can be used asan inter-frame communication channel with a techniqueknown as fragment identifier messaging. If used directly,the fragment identifier channel lacks authentication. Toprovide authentication, Windows.Live.Channels,SMash, and OpenAjax 1.1 use messaging protocols.These protocols are vulnerable to attacks on authentica-tion but can be repaired in a manner analogous to Lowe’svariation of the Needham-Schroeder protocol [23].

The postMessage communication channel sufferedthe converse security vulnerability: using frame navi-gation, an attacker can breach the confidentiality of thechannel. We propose providing confidentiality by ex-tending the postMessageAPI to let the sender specify

an intended recipient. Our proposal was adopted by theHTML 5 working group, Internet Explorer 8, Firefox 3,and Safari.

With these improvements to the browser’s isolationand communication primitives, frames are a more attrac-tive feature for integrating third-party web content. Twochallenges remain for mashups incorporating untrustedcontent. First, a gadget is permitted to navigate the top-level frame and can redirect the user from the mashup toa site of the attacker’s choice. This navigation is madeevident by the browser’s location bar, but many usersignore the location bar. Improving the usability of thebrowser’s security user interface is an important area offuture work. Second, a gadget can subvert the browser’ssecurity mechanisms if the attacker employs a browserexploit to execute arbitrary code. A browser design thatprovides further isolation against this threat is anotherimportant area of future work.

Acknowledgments

We thank Mike Beltzner, Sumeer Bhola, Dan Boneh,Gabriel E. Corvera, Ian Hickson, Koji Kato, EricLawrence, Erick Lee, David Ross, Maciej Stachowiak,Hallvord Steen, Peleus Uhley, Jeff Walden, Sam Weinig,and Boris Zbarsky for their helpful suggestions and feed-back. This work is supported by grants from the NationalScience Foundation and the US Department of Home-land Security.

References

[1] Adam Barth et al. Adopt “descendant” framenavigation policy to prevent frame hijacking.https://bugzilla.mozilla.org/show_bug.cgi?id=408052.

[2] Adam Barth and Collin Jackson. Protectingbrowsers from frame hijacking attacks, Decem-ber 2007. http://crypto.stanford.edu/frames/.

[3] James Burke. Cross domain frame communicationwith fragment identifiers.http://tagneto.blogspot.com/2006/06/cross-domain-frame-communication-with.html.

[4] Douglas Crockford. ADsafe: Making JavaScriptsafe for advertising. http://adsafe.org/.

[5] Douglas Crockford. The <module> tag.http://www.json.org/module.html.

[6] Neil Daswani, Micheal Stoppelman, et al. Theanatomy of Clickbot.A. In Proc. HotBots, 2007.

[7] Rachna Dhamija, J. D. Tygar, and Marti Hearst.Why phishing works. In CHI ’06: Proceedings ofthe SIGCHI conference on human factors in com-puting systems, 2006.

[8] Brendan Eich. JavaScript: Mobility and ubiq-uity. http://kathrin.dagstuhl.de/files/Materials/07/07091/07091.EichBrendan.Slides.pdf.

[9] Facebook. Badges. http://www.facebook.com/help.php?page=4.

[10] Facebook. Facebook Markup Language (FBML).http://wiki.developers.facebook.com/index.php/FBML.

[11] Edward W. Felten, Dirk Balfanz, Drew Dean, andDan S. Wallach. Web spoofing: An Internet congame. In Proceedings of the 20th National Infor-mation Systems Security Conference, 1996.

[12] Flickr API.http://flickr.com/services/api/.

[13] Google. Caja: A source-to-source translator forsecuring JavaScript-based web content. http://code.google.com/p/google-caja/.

[14] Google. Google Maps API.http://code.google.com/apis/maps/.

[15] iGoogle. http://www.google.com/ig.

[16] Georgi Guninski. Frame spoofing using loadingtwo frames.https://bugzilla.mozilla.org/show_bug.cgi?id=13871.

[17] Ian Hickson. Re: A potential slight securityenhancement to postMessage, Februrary 2008.http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-February/013949.html.

[18] Ian Hickson. Re: HTML5 frame navigationpolicy, April 2008. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014597.html.

[19] Ian Hickson et al. HTML 5 Working Draft.http://www.whatwg.org/specs/web-apps/current-work/.

[20] Collin Jackson, Adam Barth, Andrew Bortz, Wei-dong Shao, and Dan Boneh. Protecting browsersfrom DNS rebinding attacks. In Proceedings of ofthe 14th ACM Conference on Computer and Com-munications Security (CCS), 2007.

[21] Collin Jackson and Helen J. Wang. Sub-space: Secure cross-domain communication forweb mashups. In Proceedings of the 16th Interna-tional World Wide Web Conference. (WWW), 2007.

[22] Frederik De Keukelaere, Sumeer Bhola, MichaelSteiner, Suresh Chari, and Sachiko Yoshihama.SMash: Secure cross-domain mashups on unmodi-fied browsers. In Proceedings of the 17th Interna-tional World Wide Web Conference (WWW), 2008.

[23] Gavin Lowe. Breaking and fixing the Needham-Schroeder public-key protocol using FDR. In Pro-ceedings of TACAS, volume 1055. Springer Verlag,1996.

[24] Henry Mason. No support for MessageEvent in-terface, 2007. https://bugs.webkit.org/show_bug.cgi?id=14994.

[25] Microsoft. postMessage method.http://msdn.microsoft.com/en-us/library/cc197015(VS.85).aspx.

[26] Microsoft. SECURITY attribute.http://msdn2.microsoft.com/en-us/library/ms534622(VS.85).aspx.

[27] Microsoft. Try the Windows Live Contactscontrol. http://dev.live.com/mashups/trypresencecontrol/.

[28] Microsoft. Windows Live.http://home.live.com/.

[29] Roger M. Needham and Michael D. Schroeder.Using encryption for authentication in large net-works of computers. Communications of the ACM,21(12):993–999, 1978.

[30] National Institute of Standards and Technology.CVE-2007-5858, December 2007.

[31] Charlie Reis, John Dunagan, Helen J. Wang, Opher

Dubrovsky, and Saher Esmeir. BrowserShield:Vulnerability-driven filtering of dynamic HTML.In 7th Symposium on Operating Systems Designand Implementation (OSDI), 2006.

[32] Adam Roben et al. Change postMes-sage/MessageEvent to match HTML5 wrt. ex-posing origin vs. domain/uri. https://bugs.webkit.org/show_bug.cgi?id=17331.

[33] David Ross, 2008. Personal communication.

[34] J. Ruderman. JavaScript Security: Same Origin.http://www.mozilla.org/projects/security/components/same-origin.html.

[35] Hallvord Steen, 2008. Personal communication.

[36] Danny Thorpe. Secure cross-domain communi-cation in the browser. The Architecture Journal,12:14–18, July 2007.http://msdn2.microsoft.com/en-us/library/bb735305.aspx.

[37] Jeff Walden. Implement HTML5’s cross-document messaging API (postMessage), 2007–2008. https://bugzilla.mozilla.org/show_bug.cgi?id=387706.

[38] Jeff Walden et al. Update postMessage andMessageEvent to reflect domain/uri being re-placed by origin, optional origin argument.https://bugzilla.mozilla.org/show_bug.cgi?id=417075.

[39] Helen J. Wang, Xiaofeng Fan, Jon Howell, andCollin Jackson. Protection and communication ab-stractions for web browsers in MashupOS. In Pro-ceedings of the 21st ACM Symposium on OperatingSystems Principles (SOSP), 2007.

[40] Yahoo! My Yahoo! http://my.yahoo.com/.