figure 3: Lowe anomaly. the gadget believes the request came from
integrator.com, but in reality the request was made by attacker.
com.
updated versions of their libraries. IBM adopted our suggestions and revised their SMash14 paper.
4. 2. postmessage
HTML 510 specifies a new browser API for asynchronous
communication between frames. Unlike fragment identifier messaging, postMessage was designed for cross-ori-gin communication. The postMessage API was originally
implemented in Opera 8 and is now supported by Internet
Explorer 8, Firefox 3, Safari 3. 1, and Google Chrome. We discovered a vulnerability in an early version of the API, which
has since been eliminated by modifications we suggested.
To send a message to another frame, the sender calls the
postMessage method:
frames[0].postMessage(“Hello world.”);
In the recipient’s frame, the browser generates a message
event with the message, the origin (scheme, host, and port)
of the sender, and a reference to the sender’s frame.
security Properties: The postMessage channel guarantees
authentication, messages accurately identify their senders,
but the channel lacks confidentiality. Thus, postMessage
has almost the “opposite” security properties as fragment
identifier messaging. The postMessage channel is analogous to a channel on an untrusted network in which each
message is cryptographically signed by its sender. In both
settings, if Alice sends a message to Bob, Bob can determine
unambiguously that Alice sent the message. With postMessage, the origin property identifies the sender; with
cryptographic signatures, the signature identifies signer.
One difference between the channels is that cryptographic
signatures can be easily replayed, but postMessage resists
replay attacks.
attacks: We discover an attack that breaches the confidentiality of the postMessage channel. Because a message sent
with postMessage is directed at a frame, an attacker can
intercept the message by navigating the frame to attacker.
com before the browser generates the message event:
• recursive mashup attack: If an integrator calls postMessage on a gadget contained in a frame, the attacker can
load the integrator inside a frame and intercept the message by navigating the gadget frame (a descendant of the
attacker’s frame) to
attacker.com. When the integrator
calls postMessage on the “gadget’s” frame, the browser
delivers the message to the attacker (see Figure 4).
• reply attack: Suppose the integrator uses the origin
to decide whether to reply to a message event:
if (evt.origin == “ https://gadget.com”)
evt.source.postMessage(secret);
• The attacker can intercept the secret by navigating the
source frame before the browser generates the message
event. This attack can succeed even under the child
frame navigation policy if the honest gadget sends its
messages via top.post Mesage( . . . ). The attacker’s
gadget can embed a frame to the honest gadget and navigate the honest gadget before the integrator replies to
the “gadget’s” frame (see Figure 5).
securing postmessage: Although sites might be able to build
a secure channel using the original postMessage API, we
recommend that postMessage provide confidentiality
natively. In MashupOS,
22 we previously proposed that interframe communication APIs should let the sender specify
the origin of the intended recipient. Similarly, we propose
figure 4: Recursive mashup attack. the attacker navigates the
gadget’s frame to
attacker.com.
figure 5: Reply attack. the attacker intercepts the integrator’s
response to the gadget’s message.
