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.
17 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,
15 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.
15 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