1. Securing Frame Communication in Browsers Collin Jackson Joint work with Adam Barth and John C. Mitchell

2. Why use frames? Modularity Brings together content from multiple sources Client-side aggregation Isolation Different frames can represent different principals Can’t script each other Frame can draw only on its own rectangle Easier than sanitization src = google.com/… name = awglogin src = 7.gmodules.com/... name = remote_iframe_7

3. Threat Model • Web attacker • Controls attacker.com ($5) • Can obtain SSL/TLS certificate for attacker.com ($0) • User visits attacker.com • Optional additional assumption: Gets to embeds a malicious gadget (ad) on integrator site • Stronger threat models • Network attacker: Can inspect or corrupt traffic • Malware attacker: Already escapedfrom the browser

4. Frame Navigation Who decides a frame’s content? A frame can navigate any frame. Permissive Policy

5. window.open("https://www.attacker.com/...", "awglogin") window.open("https://www.google.com/...") Guninski Attack awglogin

6. Window Policy A frame can navigate frames in its own window.

7. Gadget Hijacking top.frames[1].location = "http:/www.attacker.com/...“; top.frames[2].location = "http:/www.attacker.com/...“; ...

8. Gadget Hijacking

9. Policy Testing

10. Ancestor Policy A frame can navigate its descendants. Parent Policy A frame can navigate its children.    

11. Frame Navigation Policies

12. Frame Navigation Policies

13. Frame Communication

14. Fragment Identifier Messaging • Send information by navigating a frame • http://gadget.com/#hello • Navigating to fragment doesn’t reload frame • No network traffic, but frame can read its fragment • Not a secure channel • Confidentiality • Integrity • Authentication   

15. Fix: Improve the protocol • Proposed Needham-Schroeder-Lowe • Adoption • Microsoft: Windows Live Channels library • IBM: OpenAjax Hub 1.1

16. postMessage    • New API for inter-frame communication • Supported in latest betas of many browsers • Not a secure channel • Confidentiality • Integrity • Authentication

17. Reply Attack

18. Fix: Improve the API • Let the sending specify the recipient • frame[0].postMessage(“Hello”, “http://gadget.com”) • Can omit argument if confidentiality not required • Adoption • Firefox 3 • Internet Explorer 8 • Safari 3.1

19. Conclusion • All proposals deployed to real users • Frame isolation • Improved frame navigation policy • Fixed Guninski and Gadget Hijacking • Drive-by-downloads still a concern… • Frame communication • Secured fragment identifier messaging • Secured new postMessage API