Securing Frame Communication in Browsers

1. 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 and integrated content called a gadget.

4. Introduction • Isolation • The integrator does not intend to communicate with the gadgets and requires only that the browser isolate frames • Google AdWords • Communication • The integrator does intend to communicate with the gadgets 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 • Controlsattacker.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 honest web site or steal sensitive information • Is constrained by the browser’s security policy and does not employ 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 ISOLATION Part I:

7. Frame Isolation • The browser’s “same-origin policy” • Restricts script running in one frame 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 = google.com/… name = awglogin src = 7.gmodules.com/... name = remote_iframe_7

8. Navigation Policy • Who decides a frame’s content? Permissive Policy A frame can navigate any frame. • 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. window.open("https://www.attacker.com/...", "awglogin") window.open("https://www.google.com/...") Cross-Window Attack The lock icon is not removed The attacker controls the password field because it is contained within a frame awglogin Or a popular blog displaying a Flash ads provided by www.attacker.com

10. Window Policy • In response to Guninski’s report, Mozilla implemented 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 the window policy • An honest principal will not embed a frame to a dishonest principal • A malicious gadget navigates a target gadget to attacker.com and impersonates the gadget to the user

12. Window Policy Anomaly Under the window policy, the attacker can navigate the other gadgets top.frames[1].location = “http://www.attacker.com/...”; top.frames[2].location = “http://www.attacker.com/...”; ...

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. A frame can navigate its children. Child Policy A frame can navigate its descendants. Descendant Policy Stricter Policies • Reverse engineer the navigation policies of existing browsers and confirmed understanding with the browsers’ developers.    

15. 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 frame could overwrite the screen real estate of the target frame • The child policy • Does not prevent additional attacks: a frame can simulate the visual 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

18. Frame Navigation Policies

19. FRAME COMMUNICATION Part II:

20. Fragment Identifier Messaging • 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

21. The data packets are observable only by the receiving frame or other pages served from the bar.com domain

22. Fragment Identifier Messaging • 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  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. A, B: Frames : Fresh nonces (random) : Location of the frame 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 recipient • 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 protocol 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 appeared to come from www.integrator.com • but in reality the request was made by www.attacker.com

25. Now Attacker successfully gets ! The attacker possesses and and can impersonate the integrator to the gadget 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

26. Secure Fragment Messaging • Lowe’s improvement of the Needham-Schroeder protocol • The responder must include his identity in the second message of the protocol • Let the honest initiator determine that an attack is in progress and abort the protocol • Adopted by: • MicrosoftWindows 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  Other frames from other origin can read the message  Can’t be tampered with portions of messages  The origin property accurately identifies the sender 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 the 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 newpostMessage 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.