SMash : Secure Component Model for Cross-Domain Mashups on Unmodified Browsers

1. SMash : Secure Component Model for Cross-Domain Mashups on Unmodified Browsers WWW 2008 Frederik De Keukelaere et al. Presenter : SJ Park

2. Table of Contents • Introduction • Problems • Secure Component Model • Solution Overview • Solution Details • Performance Evaluation • Summary

3. Introduction (1/2) Mashups • Definition • Applications which mix and merge content coming from different content providers • Interface • Public interface like API • Web feeds like RSS • Example • Use of used car data from Google Maps to add additional information • News aggregation • Many companies, such as eBay, Google, and so on, provide API for mashup application.

4. Introduction (2/2) Mashup Example

5. Problems • Security • No mechanism to protect contents from other provider’s script • Requiring a sound security foundation protecting the interests of the various involved parities • Browser Limitation • Content from different origins can not interact with each other. • Current solutions are proxy server and <script> tag.

6. Secure Component Model (1/3) Model • Component • Frame for a content • Port • Types of input and output • Event hub • A publish/subscribe system with many-to-many channels • Communication channel

7. Secure Component Model (2/3) Security Requirement • The DOM tree of each component is totally isolated from other components. • The JavaScript namespace is completely isolated from other components • Components can be loaded directly from the component provider. • Inter-component communication is secure. • Component loading and unloading is completely under the control of the mashup application.

8. Secure Component Model (3/3) Implementation Background • Document Object Model(DOM) • Unit to represent an HTML document loaded in a browser • domain • DOM’s property which is the hostname of the server • Numeric IP address or DNS domain name • location • DOM’s property that represents the URL of the document • Change of fragment ID doesn’t cause a web page reloading. • ex) http://www.foo.org/foo.html#fragment-identifier • <iframe> tag • A document with domain and location attributes • Frame can embed sub-frames, forming a frame hierarchy. • Even if frames are from different domains, a frame can write the location property of any frame in the same frame hierarchy, regardless of origin.

9. Solution Overview (1/2) Figure : Isolated Components

10. Solution Overview (2/2) Key Features • Component isolation • using <iframe> tag • Component-mashup communication link • Using fragment identifier of the location property of the iframe • Based on observation that parent can write to the child’s location property • Link security • Link security is guaranteed with frame hierarchy. • Link integrity is guaranteed with a shared secret token. • Protection from frame-phishing • Navigating a component away from it’s URL to another • To protect it, using event handlers, timeouts, and communication using the tunnel iframe

11. Solution Details (1/4) Figure : Layered Communication Stack

12. Solution Details (2/4) Layers • Event hub layer • Loading and unloading components • Creating and deleting channels • Wiring the ports of the components to channels • Event communication layer • Composing the messages used to multiplex the multiple component ports on a single link • Fragment communication layer • Layer aware of the use of fragment IDs to communicate between components and the mashup application • Possible to employ another communication mechanism

13. Solution Details (3/4) Fragment Communication and Link Integrity • Fragment Communication • Long messages have to be split into segmentsbecause of the URL length limitation. • Using periodic timer to read a message • Process • Component writes a message to the fragment ID in the tunnel’s location property. • Component has to wait until the previous message has been read by tunnel. • When the tunnel has read the previous message, it sends ack message. • Link Integrity • Malicious component can modify the location property. • In each message, it embeds a shared secret to authenticate a component.

14. Solution Details (4/4) Protection from Frame Phishing • Using a combination of onunload handler, timeouts, and communication using tunnel iframe • In case of being replaced by attacker • Component’s onunload handler is invoked. • However, there is no guarantee that communication will success before the unload complete. • Instead, using the tunnel’s onunload handler. (Java script function call) • In case of being replaced before the tunnel iframe is load • Setting a timeout in the mashup application • If this timeout expires, an application specific error handler is called.

15. Performance Evaluation (1/4) Metrics • Event Rate • Sustainable maximum event rate • Data Throughput • Maximum rate in KB/sec • Transfer l MB data from the mashup application to components • Component Load Latency • Latency to load a component and setup the communication link between mashup app and component

16. Performance Evaluation (2/4) Event Rate

17. Performance Evaluation (3/4) Data Throughput

18. Performance Evaluation (4/4) Component Load Latency

19. Summary • Use browser's same-origin policy to enforce isolation of providers' content • Implement a robust message-passing system based on setting fragment identifiers • Be resilient to attacks such as channel spying, message forging, and frame-phishing