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

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

Mashups 3  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. Introduction (1/2)

Mashup Example 4 Introduction (2/2)

Problems 5  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 tag.

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

Security Requirement 7  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. Secure Component Model (2/3)

Implementation Background 8  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)  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. Secure Component Model (3/3)

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

Key Features 10  Component isolation  using 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 Solution Overview (2/2)

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

Layers 12  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 Solution Details (2/4)

Fragment Communication and Link Integrity 13  Fragment Communication  Long messages have to be split into segments because 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. Solution Details (3/4)

Protection from Frame Phishing 14  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. Solution Details (4/4)

Metrics 15  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 Performance Evaluation (1/4)

Event Rate 16 Performance Evaluation (2/4)

Data Throughput 17 Performance Evaluation (3/4)

Component Load Latency 18 Performance Evaluation (4/4)

Summary 19  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