1 / 45

Mashup Security by Compilation

Mashup Security by Compilation. Tamara Rezk These slides discuss joint work with Zhengqin Luo and Jos e Santos February 22 nd , 2013. Web Client Mashup. Client-side web application Integrating third-party gadgets Great way for code reuse!. Integrator’s Housing Data.

kacy
Télécharger la présentation

Mashup Security by Compilation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Mashup Security by Compilation Tamara Rezk These slides discuss joint work with ZhengqinLuo and Jose Santos February 22nd , 2013

  2. Web Client Mashup • Client-side web application • Integrating third-party gadgets • Great way for code reuse! Integrator’s Housing Data Google Maps Gadget

  3. Different kind of Mashups gadget The integrator uses the gadget as a library The gadget reads state from the integrator

  4. Programming model • Mashups written in HTML + Javascript; • Two ways to include external gadgets: • Using script tag • Using frame tag

  5. Script tag - oversharing • Gadget has integrator privileges • Full exposure JS execution environment <scriptsrc="http://maps.google.com/maps/api/js?sensor=true"></script> Google Maps Gadget Integrator’s Housing Data

  6. Script tag – security violations • Confidentiality violation var steal = window[“integratorSecret”] • Integrity violation window[“price”] = newPrice <scriptsrc="http://maps.google.com/maps/api/js?sensor=true"></script> Google Maps Gadget Integrator’s Housing Data

  7. Script tag – integrity violation <html> <head> <script src=http://untrusted.com/untrustedAD.js></script> </head> <body> <script> varfac= function(x) { if (x <= 1) { return 1; } return x*fac(x-1); } r = fac(3); s = "alert("+r+")“ setTimeout(s, 100) </script> </body></html>

  8. Script tag - integrity violation Content of http://untrusted.com/untrustedAD.js setTimeout= function() { EVIL CODE HERE }

  9. Embedded frame – undersharing • Gadget has no privileges • Isolation of JS execution environment between integrator and gadget • Same Origin Policy <iframesrc="http://mapservice.com/maps.html"></iframe> X Google Maps Gadget Integrator’s Housing Data

  10. Embedded frame – undersharing Isolation of JS execution: • Confidentiality violation var steal = window[“integratorSecret”] • Integrity violation window[“price”] = newPrice <iframesrc="http://mapservice.com/maps.html"></iframe> • X X Google Maps Gadget Integrator’s Housing Data

  11. Script versus Frame Tag • Script tag: • exposes the integrator’s JS environment • unlimited communication • not secure • Frame tag: • isolates the environment of gadget and integrator • communication is limited • more secure than script In practice: sacrifice security in the name of functionality!

  12. HTML5 and Inter-frame communication listener in gadget • Frame can communicate with integrator via PostMessage: • confidentiality • authentication listener in integrator Gadget Integrator

  13. HTML5 and Inter-frame communication Stublibrary in gadget • The Postmash design was proposed by Barth, Jackson, and Li [09] • Put untrusted code in embedded frame; • Two stub libraries; • Proxy e.g. method invocation by message-passing; • No need to change untrusted code !! Stub library in integrator Google Maps Gadget Integrator’s Housing Data

  14. Postmash • How to transform an insecure mashup to a mashup following the Postmash design? • Manually writing two stub libraries (gadget dependent); • Manually rewriting of integrators’ code; • Our proposal : automate it and characterize the security property that it enforces: Mashic Compiler [CSF’ 12]

  15. Our proposal: Mashic Compiler • A generic proxy and listener library • Gadget independent! • Integrator transform: • Adapt to asynchronous communication, • Use the proxy library • Mashic compiler • Input: insecure mashup • Output: secured mashup • Proofs: • Correctness • benign gadget • Security • JS small-step semantics of Maffeis et al. with rules to model the same origin policy

  16. Mashic compiler - Overview <html> <iframesrc = u’> </iframe> <script> Proxy </script> <script> Bootstrap-I</script> <script> C(I) </script> </html> where Web(u’ ) = <script> Listener </script> <script src = u> </script> <script> • Pg: gadget code • Pi : integrator code Mashic compiler <html> <script src = u> </script> <script> I </script> </html>

  17. Opaque Handle • Opaque Handles • Integrator’s reference to gadget’s object • E.g.: { is_handle: true id : 42} • Inside gadget • 42 maps to the real object. • Gadget independent! Integrator Framed gadget

  18. Proxy and listener • Proxy provides interfaces using opaque handles: • Example: GET_PROPERTY(ohandle,prop,cont) • Send (“get property”, ohandle, prop) via Postmessage • Listener reacts to message: • E.g. if ohandle { is_handle: true, id : 42} -> { “prop”: 4}, then listener responds with 4. • Proxy receives the response, applies the continuation cont to 4. Integrator Framed gadget

  19. A minimal set of Proxy Interfaces • GET_GLOBAL_REF • Get global property • CALL_METHOD • Call a method • CALL_FUNCTION • Call a function • ASSIGN_PROPERTY • Property assignment • General enough to encode most real-world mashups!!

  20. Integrator transformation • PostMessage is asynchronous; • So is our proxy interface; • Automated CPS transformation and call to proxy interfaces of old integrator code • An example of rule

  21. Realistic core JS subset • Small-step core JS semantics adopted from Maffeis et al. [08]; • Extended with DOM semantics and message-passing; • A decorated (colored heap) semantics;

  22. Decorated Semantics heaps contain objects with properties that are colored programs run as colored principal

  23. Formal Guarantees • Correctness guarantees: • If the gadget is benign, then the compiled mashupbehavesas the original one. • Security guarantees: • If the gadget is not benign, nothing “bad” can happen in the compiled mashup.

  24. Benign gadget Intuitively: • Integrity: A gadget does not try to write a property belonging to the integrator; • Confidentiality: A gadget does not try to read a property of the integrator; • Formally defined:

  25. Correctness Theorem For a benign gadget, the compiled mashup reaches a final configuration indistinguishable with the one reachable from the original mashup.

  26. Security Theorem For any gadget, the compiled mashup provides integrity and confidentiality for the integrator.

  27. Prototype Implementation • A prototype compiler written in Bigloo(a dialect of scheme) • 3.3k loc of bigloo and 0.8k loc of Javascript • Applied to various mashups:

  28. Mashic: Summary Theorem Plus Assumption Theorem Benign Gadget: Passive Gadget The compiled mashup preserves the original semantics Security Correcteness After Mashic compilation, the malicious gadget cannot read/write information belonging to the integrator. Browser Independence Gadget Independence

  29. Extending Mashic Challenge How? Handle Active Gadgets Gadgets must be allowed to access integrator objects Add an Access Control layer between gadgets and the integrator

  30. Supporting Active Gadgets Integrator.js Allow two-sided communication Integrator Listener iframe Proxy Current Mashic Uncontrolled Control the communication from the gadget to the integrator Add proxy and listener libraries to both the gadget iframe and to the integrator code Goal Controlled Gadget A Page.html Listener Proxy

  31. Controlling Gadget – Integrator Com. vlwhere l is in LcxLI Integrator.js How? Integrator LI Lc Listener Assign a security level to each integrator resource Assign a security level to each gadget Check all the gadget – integrator accesses at runtime Establish a lattice of security levels 1 2 3 4 iframe Proxy Uncontrolled Controlled Gadget A Confidentiality Integrity Page.html LcxLI ∑ : Gadgets → LcxLI Listener Proxy Gadget A

  32. Ext Mashic: Soundness and Security Theorem Assumption Theorem Benign Gadget: A gadget that only tries to access integrator information compatible with its security level The compiled mashup preserves the original semantics Security Correcteness After Mashic compilation, the malicious gadget can only read/write integrator information compatible with its security level.

  33. Information Flow control neededfor the integrator code!(and only the integrator code)

  34. Information Flow Control needed • Separation of the gadget using iframe: no need to analyze gadget code • Existing work on dynamic monitors (browser dependent): • Hedin and Sabelfeld, 12 • Austin and Flanagan, 09,10,12 • Inlining of dynamic security monitors (browser independent) : • Sabelfeld et al ‘’10 • Chudnov and Naumann’ 10

  35. Information Flow Control Labeling in JavaScript LI Lc var o = {}; o[f()] = 1 Confidentiality Integrity LcxLI • f() is a function that returns a dynamically computed string In the final memory o has a new property unknown before execution!Static labeling is not always possible.

  36. Labeling Values LabeledObject Original Object p1: v1 RuntimeLabeling p1: (v1,,l1) p2: v2 p2: (v2, l2) p3: v3 p3: (v3, l3) … SecurityLeveloftheobject … Security levels of the object property values pn: vn pn: (vn, ln) lo: l

  37. Labeling Values and Instrumentation Source Integrator Code Source Integrator Code … if(x) { y = y + x; } else { alert(“hello world”) } … if(x.value) { lpc = x.level ˅ lpc; y.value = y.value + x.value; y.level = x.level ˅ y.level˅ lpc; } else { alert(“hello world”) }

  38. Labeling Values and Instrumentation Source Integrator Code Source Integrator Code code instrumentation: a new object for each value in the program! … if(x) { y = y + x; } else { alert(“hello world”) } … if(x.value) { lpc = x.level ˅ lpc; y.value = y.value + x.value; y.level = x.level ˅ y.level˅ lpc; } else { alert(“hello world”) }

  39. Labeling Properties LabeledObject Original Object p1: v1 RuntimeLabeling (p1,l1) : v1 p2: v2 (p2 ,l2): v2 p3: v3 … … pn: vn (pn,ln) : vn lo: l

  40. Labeling Properties LabeledObject Original Object p1: v1 RuntimeLabeling (p1,l1) : v1 code instrumentation: a property for each object (mapping properties of the object to labels) p2: v2 (p2 ,l2): v2 p3: v3 … … pn: vn (pn,ln) : vn lo: l

  41. Labeling Properties • Inlining security monitors becomes more efficient (no need for an object per value in the program) • Opens the path to combining dynamic and static JavaScript analysis

  42. Dynamic Semantics, extracting constrains constrains

  43. Conclusions Mashic Compiler: • assumption: gadgets used as libraries • correctness under assumption • security guarantees based on SOP, characterized as IF where everything in the integrator is treated as top security level • compilation: gadget and browser independent!

  44. Conclusions Mashic Compiler Extension: • assumption: two way communication with AC • correctness under assumption • security guarantees based on information flow security • compilation: • IF analysis for the integrator using code instrumentation • gadget independence regarding IF analysis • browser independence

  45. Open Questions • IF analysis for the integrator using code instrumentation: • Combining with static analysis? If part of the code is in a static typable subset [Maffeis 2010] then type check and instrument the rest. • Gadget independence regarding IF analysis: • Still have to adapt to asynchrony of PostMessage … what’s a good solution to this? shadow pages? [Adjail 2010] • Making the web ad business model secure and practical?

More Related