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.

6

FRAME ISOLATIONPart I:

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

15

Policy Behavior

Permissive

Window

Descendant

Child

Policy Behavior

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 ?

19

FRAME COMMUNICATIONPart II:

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

34

Comments

• All proposals deployed to real users

• Gain more understanding about how modern browsers are designed to perform frame security

• With these improvements, frames are a more attractive feature for integrating third-party web content

• Everything updated so fast.