policy prevents other origins from eavesdropping on messages because they are unable to read the frame’s location (even though the navigation policy lets them write the frame’s location). Browsers also prevent arbitrary origins from tampering with portions of messages. Other security origins can, however, overwrite the fragment identifier in its entirety, leaving the recipient to guess the sender of each message.

To understand these security properties, we draw an analogy with the well-known properties of network channels. We view the browser as guaranteeing that the fragment identifier channel has confidentiality: a message can be read only by its intended recipient. The fragment identifier channel fails to be a secure channel, however, because it lacks authentication: a recipient cannot determine the sender of a message unambiguously. The attacker might be able to replay previous messages using the browser’s history API.

The fragment identifier channel is analogous to a channel on an untrusted network in which each message is encrypted with the public key of its intended recipient. In both cases, when Alice sends a message to Bob, no one except Bob learns the contents of the message (unless Bob forwards the message). In both settings, the channel does not provide a reliable procedure for determining who sent a given message. There are two key differences between the fragment identifier channel and the public-key channel:

 

1. Public-key channel is susceptible to traffic analysis, but an attacker cannot determine the length of a message sent over the fragment identifier channel. An attacker can extract timing information by polling the browser’s clock, but obtaining high-resolution timing information degrades performance.

2. Fragment identifier channel is constrained by the browser’s frame navigation policy. In principle, this could be used to construct protocols secure for the fragment identifier channel that are insecure for the public-key channel (by preventing the attacker from navigating the recipient), but in practice this restriction has not prevented us from constructing attacks on existing implementations.

 

Despite these differences, we find the network analogy useful in analyzing interframe communication.

Windows live Channels: Microsoft uses fragment identifier messaging in its Windows Live platform library to implement a higher-level channel API, Microsoft.Live. Channels. The Windows Live Contacts gadget uses this

21

API to communicate with its integrator. The integrator can instruct the gadget to add or remove contacts from the user’s contacts list, and the gadget can send the integrator details about the user’s contacts. Whenever the integrator asks the gadget to perform a sensitive action, the gadget asks the user to confirm the operation and displays the integrator’s host name to aid the user in making trust decisions. Prior to our analysis, Microsoft.Live.Channels used a protocol to add authentication to the fragment identifier channel. By reverse engineering the implementation, we determined

88 COmmuniCatiOns Of the aCm | June 2009 | VoL. 52 | no. 6

that the library used the following protocol to establish a secure channel:

A®B : N , URI

AA B®A : N , N

AB

A ® B : N , Message B1

 

In this notation, A and B are frames, N and N are fresh

AB

nonces (numbers chosen at random during each run of the protocol), and URI is the location of A’s frame. Under the

A

network analogy described above, this protocol is analogous to the classic Needham–Schroeder public-key protocol. ¹⁷ The Needham–Schroeder protocol was designed to establish a shared secret between two parties over an insecure channel. Instead of using encryption as in the Needham–Schroeder protocol, Windows Live relies on the fragment identifier channel to provide confidentiality.

The Needham–Schroeder public-key protocol has a well-known anomaly, due to Lowe, ¹⁵ that leads to an attack in the browser setting. In the Lowe scenario, an honest principal, Alice, initiates the protocol with a dishonest party, Eve. Eve then convinces honest Bob that she is Alice. In order to exploit the Lowe anomaly, an honest principal must be willing to initiate the protocol with a dishonest principal. This requirement is met in mashups because the integrator initiates the protocol with the gadget attacker’s gadget when the mashup is initialized. The Lowe anomaly can be exploited to impersonate the integrator to the gadget:

Integrator ® Attacker : N , URI

II Attacker ® Gadget : N , URI II

Gadget ® Integrator : N , N

IG
Integrator ® Attacker : N , Message
G1

After these four messages, the attacker possesses N and

I

N and can impersonate the integrator to the gadget. We G

have implemented this attack against the Windows Live Contacts gadget. The anomaly is especially problematic for the Contacts gadget because it displays the integrator’s host name to the user in its security user interface (see Figure 3). securing Fragment Identifier messaging: The channel can be secured using a variant of the Needham–Schroeder–Lowe protocol. ¹⁵ As in Lowe’s improvement to the original protocol, we recommend including the responder’s identity in the second message of the protocol, letting the honest initiator detect the attack and abort the protocol:

A ®B : N , URI

AA
B® A : N ,N , URI
AB B
A ®B : N
B

We contacted Microsoft, the OpenAJAX Alliance, and IBM about the vulnerabilities in their fragment identifier messaging protocols. Microsoft and the OpenAJAX Alliance have adopted our suggestions and deployed the above protocol in