Securing Frame Communication in Browsers
Learn how to secure frame communication in browsers to prevent attacks and enhance confidentiality, integrity, and authentication. Discover the latest APIs and protocols for safe inter-frame messaging.
Securing Frame Communication in Browsers
E N D
Presentation Transcript
Securing Frame Communication in Browsers Collin Jackson Joint work with Adam Barth and John C. Mitchell
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
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
Frame Navigation Who decides a frame’s content? A frame can navigate any frame. Permissive Policy
window.open("https://www.attacker.com/...", "awglogin") window.open("https://www.google.com/...") Guninski Attack awglogin
Window Policy A frame can navigate frames in its own window.
Gadget Hijacking top.frames[1].location = "http:/www.attacker.com/...“; top.frames[2].location = "http:/www.attacker.com/...“; ...
Ancestor Policy A frame can navigate its descendants. Parent Policy A frame can navigate its children.
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
Fix: Improve the protocol • Proposed Needham-Schroeder-Lowe • Adoption • Microsoft: Windows Live Channels library • IBM: OpenAjax Hub 1.1
postMessage • New API for inter-frame communication • Supported in latest betas of many browsers • Not a secure channel • Confidentiality • Integrity • Authentication
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
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