Securing Frame Communication in Browsers
Adam Barth, Collin Jackson, and John C. Mitchell, Stanford University
In Proceedings of the 17th USENIX Security Symposium, 2008
2
Outline
• Introduction• Threat Model• Frame Isolation
– Cross-Window Attacks– Same-Window Attacks– Stricter Policies– Deployment
• Frame Communication– The Fragment Identifier Channel– The postMessage Channel
• Conclusions and Comments
3
Introduction
• Mashup– A web site combining content from multiple sources to
create a single user experience– The party combining the content called the integrator a
nd integrated content called a gadget.
4
Introduction
• Isolation– The integrator does not intend to communicate with th
e gadgets and requires only that the browser isolate frames
• Google AdWords
• Communication– The integrator does intend to communicate with the g
adgets and requires secure inter-frame communication
• iGoogle, Yelp
• Goal: Isolating untrusted, or partially trusted, software components while providing secure inter-component communication
5
Threat Model• Concerned with securing in-browser interaction from
malicious attackers. Focus on privileges the browser itself affords the attacker to interact with honest sites
• Web Attacker– Owns one or more machines on the network
• Control one or more machine on the network– Controls attacker.com
• The browser gets and renders contents from the attackers’ web site– User visits attacker.com
• Can obtain SSL certificate for attacker.com– Attempts to disrupt interaction between a honest user and an h
onest web site or steal sensitive information– Is constrained by the browser’s security policy and does not emp
loy a browser exploit to circumvent the policy• Gadget Attacker
– Web attacker with one additional ability: the integrator embeds a gadget of the attacker’s choice.
7
Frame Isolation
• The browser’s “same-origin policy” – Restricts script running in one f
rame from manipulating content in another frame
• Can’t script each other
• The browser’s “frame navigation policy”– Determines whether one frame
is allowed to navigate (change the location of) another frame
– Overly permissive navigation policy leads to attacks
src = 7.gmodules.com/...name = remote_iframe_7
src = google.com/…name = awglogin
8
A frame can navigate any frame.
Navigation Policy
Permissive Policy
• Who decides a frame’s content?
– otherWindow includes a frame. This navigates the frame to https://attacker.com/. Replaces the frame’s document with content retrieved from that URL
– Requests the browser search for a frame named frameName and navigate the frame to the specified URL
9
Or a popular blog displaying a Flash ads provided by www.attacker.com
Cross-Window Attack
window.open("https://www.google.com/...")window.open("https://www.attacker.com/...", "awglogin")
awglogin
The lock icon is not removedThe attacker controls the password field
because it is contained within a frame
10
Window Policy• In response to Guninski’s report, Mozilla impleme
nted a stricter policy in 2001
• Web attacker does not control a frame in the same window as the CitiBank or the Google AdSense login page. – the attacker cannot navigate the login frame to attacker.
com
A frame can navigate frames in its own window.
Window Policy
11
Same-Window Attack
• Gadget Hijacking Attacks– Mashups invalidate an implicit assumption of t
he window policy• An honest principal will not embed a frame to a dis
honest principal
– A malicious gadget navigates a target gadget to attacker.com and impersonates the gadget to the user
12
Window Policy Anomaly
top.frames[1].location = “http://www.attacker.com/...”;top.frames[2].location = “http://www.attacker.com/...”;
...
Under the window policy, the attacker can navigate the other gadgets
13
Gadget Hijacking Attacks
• Aggregator Vulnerabilities– one popular iGoogle gadget: Let users access their
Hotmail inbox • If the user is not logged into Hotmail, the gadget requests the
user’s Hotmail password
– A malicious gadget can replace the Hotmail gadget with content that asks the user for his or her Hotmail password.
• Advertisement Vulnerabilities– An attacker who provides such an advertisement can
steal advertising impressions allotted to other advertisers
14
Stricter Policies
• Reverse engineer the navigation policies of existing browsers and confirmed understanding with the browsers’ developers.
A frame can navigateits children.
Child Policy
A frame can navigateits descendants.
Descendant Policy
16
Pixel Delegation
• The browser prevents the child frame from drawing outside of its bounding box
• Allows the parent frame to draw over the child using “position: absolute” stlye
• The descendant policy– permits a frame to navigate a target frame precisely when the fr
ame could overwrite the screen real estate of the target frame
• The child policy– Does not prevent additional attacks: a frame can simulate the vis
ual effects of navigating a grandchild frame by drawing over the region of the screen occupied by the grandchild frame
– Incompatible with a large number of web sites
17
Frame Navigation Policies
Browser Policy
IE 6 (default) Permissive
IE 6 (option) Child
IE7 (no Flash) Descendant
IE7 (with Flash)
Permissive
Firefox 2 Window
Safari 3 Permissive
Opera 9 Child
18
Frame Navigation Policies
Browser Policy
IE7 (no Flash) Descendant
IE7 (with Flash)
Descendant
Firefox 3 Descendant
Safari 3 Descendant
Opera 9 ?
20
• Send information by navigating a frame– frames[0] is currently located at http://example.com/doc
– frames[0].location = “http://example.com/doc#message”
– The frame periodically polling window.location.hash to see it if fragment identifier has changed
Fragment Identifier Messaging
21
The data packets are observable only by the receiving frame or other pages served from the bar.com domain
22
• Is found but not designed
• Navigating to fragment doesn’t reload frame– No network traffic, entirely in the browser, but
frame can read its fragment
• Not a secure channel– Confidentiality
– Integrity
– Authentication
Fragment Identifier Messaging
Other frames from other origin can’t read the frame’s location
Can’t be tampered with portions of messages
Other security origins can overwrite in its entirety, leaving the recipient to guess the sender of each message
23
Windows Live Channels
• Analogous to a channel on an untrusted network secured by a public-key cryptosystem– Each message is encrypted with the public key of its intended reci
pient• Microsoft.Live.Channels
– Microsoft uses the fragment identifier channel in its Windows Live platform library to implement a higher-level channel API
– The Windows Live Contacts gadget use this API to communicate with its integrator
• Needham-Schroeder key-establishment protocolA, B: Frames
: Fresh nonces (random)
: Location of the frame
No need encryption because already provides the require confidentiality
24
The Lowe Anomaly• Lowe scenario
– an honest principal, Alice, initiates the protocol with a dishonest party, Eve. Eve then convinces honest Bob that she is Alice
– an honest principal must be willing to initiate the protocol with a dishonest principal
• A Windows Live Contacts gadget – received a message that ap
peared to come from www.integrator.com
– but in reality the request was made by www.attacker.com
25
The Lowe Anomaly• received a message that appeared to come from www.integrator.com• but in reality the request was made by www.attacker.com
The honest principal initiates the protocol
Gadget thinks it’s from Integrator
Integrator thinks it’s from Attacker
Now Attacker successfully gets !
The attacker possesses and and can impersonate the integrator to the gadget
26
Secure Fragment Messaging• Lowe’s improvement of the Needham-Schroe
der protocol– The responder must include his identity in the second
message of the protocol– Let the honest initiator determine that an attack is in pr
ogress and abort the protocol
• Adopted by:– Microsoft Windows Live
Channels library– IBM Smash paper– OpenAjax Alliance
, URIG
27
Secure Fragment Messaging
• A new API for inter-frame communication– Designed for cross-site communication
• Supported in latest betas of many browsers
• To send a message to another frame, the sender calls the postMessage method:
• The browser then generates a message event in the recipient’s frame that contains – Message– Origin (scheme, port, and domain) of the sender– JavaScript pointer to the frame that sent the message
28
The postMessage Channel
• Analogous to a channel on a untrusted network secured by an existentially unforegeable signature scheme
• Not a secure channel– Confidentiality– Integrity– Authentication The origin property accurately identifies the sender
Other frames from other origin can read the message
Can’t be tampered with portions of messages
If the attacker navigates that frame to attacker.com before the message event is generated, the attacker will receive the message instead of the intended recipient.
29
Recursive Mashup Attack
• After the attacker loads the integrator inside a frame, the attacker navigates the gadget frame to attacker.com
• Integrator calls postMessage on the “gadget’s” frame– the browser delivers the message to the attacker whose content
now occupies the “gadget’s” frame
30
Reply Attack
• The source attribute of the MessageEvent is a JavaScript reference to the frame that sent the message.
• It is tempting to conclude that the reply will be sent to https://b.com
An attacker might be able to intercept the message!
31
• The honest gadget calls top.postMessage("Hello")– The gadget attacker can intercept the message by embedding th
e honest gadget in a frame• After the gadget posts its message to the integrator, the
attacker navigates the honest gadget to https://attacker.com. – Permitted under both the child and descendant policies
• Result: When the integrator replies to the source of the message, the message will be delivered to the attacker instead of to the honest gadget.
32
Securing postMessage
• Add the origin of the intended recipient as a second parameter– The browser will deliver the message to the targeted
frame only if that frame’s current security origin matches the argument
– Can omit argument if confidentiality not required
• Adopted by:– Firefox 3– Safari 3.1– IE 8
33
Conclusions
• Web applications rely on the browser to isolate frames from different security origins and to provide secure inter-frame communication.
• Frame isolation– Improved frame navigation policy
• Fixed Guninski and Gadget Hijacking
• Frame communication– Secure fragment identifier messaging– Secure new postMessage API