Sandboxing Java Script via Libraries and Wrappers Phu
Sandboxing Java. Script via Libraries and Wrappers Phu H. Phung University of Gothenburg, Sweden, and University of Illinois at Chicago
About Me • Receipt of international postdoc grant (3 years) by Swedish Research Council (VR), employed by Univ. of Gothenburg. • Research Associate at UIC. • Ph. D in Computer Science in 2011 from Chalmers University, Sweden. Hosted by OWASP & the NYC Chapter
• Selected research projects – European Web. Sand (complete) • End-to-end secure web framework – Secure Web Advertisements, funded by NSF (on-going) – Defensive Optimizing Compiler, funded by DARPA (on-going) Hosted by OWASP & the NYC Chapter
This talk • Based on the two published papers: – PH Phung, L Desmet. A two-tier sandbox architecture for untrusted Java. Script, invited paper, JSTools’ 12. – P Agten, S Van Acker, Y Brondsema, PH Phung, L Desmet, F Piessens. JSand: complete client-side sandboxing of third-party Java. Script without browser modifications, ACSAC’ 12.
![92% of all websites use Java. Script [w 3 techs. com] “ 88. 45%](http://slidetodoc.com/presentation_image_h/15a09b6190a85ab2f99593df19fb6adc/image-5.jpg "92% of all websites use Java. Script [w 3 techs. com] “ 88. 45%")
92% of all websites use Java. Script [w 3 techs. com] “ 88. 45% of the Alexa top 10, 000 web sites included at least one remote Java. Script library” CCS’ 12 5
Third-party Java. Script is everywhere • Advertisements – Adhese ad network • Social web – – Facebook Connect Google+ Twitter Feedsburner • Tracking – Scorecardresearch • Web Analytics – Yahoo! Web Analytics – Google Analytics • … 6
Two basic composition techniques Iframe integration <html><body> … <iframe src=“http: //3 rdparty. com/frame. html”> </iframe> … </body></html> 3 rd party 7
Two basic composition techniques Script inclusion <html><body> … <script src=“http: //3 rdparty. com/script. js”> </script> … </body></html> 3 rd party 8
Third-party Java. Script issues • Third-party script inclusion run with the same privilege of the hosting page. • Security issues: – Malicious third-party code – Trusted third-party is compromised – Confidentiality, integrity, and other security risks 9
Difficult issues with Java. Script • Java. Script is a powerful language, but the language design is bad for security, e. g. : – Dynamic scripts: document. write, eval, . . . – Encapsulation leakage –. . . A lot of <script> document. write(‘<scr’); document. write(‘ipt> malic’); var i= 1; document. write(‘ious code; </sc’); document. write(‘ript>’); </script> attacks were launched in practice <script> malicious code; </script> 10
Malicious third-party Java. Script example The most reliable, cost effective method to inject evil code is to buy an ad. Principles of Security. Douglas Crockford http: //fromonesrc. com/blog/page/2/
An attack scenario Million Browser Botnet (July 2013) – Leverage Advertising Networks using Java. Script to launch Application-Level Jeremiah Grossman & Matt Johansen DDo. S White. Hat SECURITY – Paid on 2 ad networks for displaying treacherous advertisements on pages visited by hundreds of thousands of people – One day, got 13. 6 million views of the ads, just spent less than $100 12
State-of-the-art • Limit third-party code to safe subset of Java. Script – Facebook JS, ADSafety, . . . No compatibility with existing scripts • Browser-based sandboxing solutions – Con. Script, Web. Jail, Contego, . . . Browser modifications imply short-term deployment issues • Server-side transformations of scripts to be included – Google Caja, Browser. Shield, . . . No direct script delivery to browser Great runtime overhead 13
Our approach • A sandbox model for third-party Java. Script – Using only JS libraries and wrappers – Whitelist (least-privilege) implementation approach • Only properties and objects defined in policies are available to the untrusted code – No browser modification is required – The third-party code is keep in original – Easily dealing with dynamic features of Java. Script “Lightweight Self-Protecting Java. Script”, ASIACCS’ 09 14
Two-tier sandbox architecture Base-line API implementation, in e. g. `api. js’ file Sandbox running policy code, defined in a separate JS e. g. `policy. js’ Sandbox running untrusted code, defined in a separate file e. g. `untrusted. js’ The policy code can only access the base-line API and provided wrapper functions (ensuring no leaks to global) The untrusted code can only access objects returned by the outer sandbox Java. Script environment, e. g. the DOM
Two-tier sandbox architecture var api = load. API(…); var outer. Sandbox = caja. VM. compile. Module(policy. Code); var enforced. API = outer. Sandbox(api); var inner. Sandbox = caja. VM. compile. Module(untrusted. Code); inner. Sandbox(enforced. API); 16
The architecture in multipleprincipal untrusted code Base-line API implementation, in e. g. `api. js’ file Policy 1 untrusted Policy 2 untrusted Policy 3 untrusted 17
Sandboxing untrusted code • Use Secure ECMAScript (SES) library developed by Google Caja team – Load a piece of code to execute within an isolated environment • The code can only interact with the outside world via provided APIs var api = {. . . }; //constructing var make. Sandbox = caja. VM. compile. Module(untrusted. Code. Src); var sandboxed = make. Sandbox(api); 18
Isolation technique: The SES library Object-capability environment • Scripts can access – Objects they create themselves – Objects explicitly handed to them untrusted. Code API sandbox Global context 19
Isolation technique: The SES library 20
Base-line APIs implementation • Create a Virtual DOM – Intercepting wrapper around real DOM – Use Harmony Proxies to generically intercept property accesses on objects • Virtual DOM implementation uses the Membrane Pattern – Wrap any object passed from DOM to sandbox (return values) – Unwrap any object passed from sandbox to DOM (arguments) 21
Wrapper example 22
Policy definition • Base-line APIs implementation – Can enforce coarse-grained, generic policies, e. g. : • Sanitize HTML • Ensure complete mediation • Fine-grained policies for multiple untrusted Java. Script code – Modular, principal-specific, e. g. : script 1 is allowed to read/write elemt_A, script 2 is allowed to read elemt_A – Stafeful, e. g. : limit the number of popups to 3 – Cross-principal stateful policies, e. g: after script 1 write to elemt_A, disallow access from script 2 to elemt_A 23
Deployment model • Untrusted code is loaded into a string variable – Using server-side proxy + XMLHttp. Request (to overcome same origin policy) – CORS (Cross-Origin Resource Sharing) /UMP(Uniform Messaging Policy) headers set by the script provider <script src= “http: //3 rdparty. com/script. js”> </script> before <script src=“ses. js”></script> <script src=“api. js”></script> <script src=“policy 0. js”></script> <script> var script = get(“http: //3 rdparty. com/script. js”); ses. execute(script, policy 0); </script>
Secure dynamic script evaluation • Special handlers to intercept all methods that allow script tags to be added – node. append. Child, node. insert. Before, node. replace. Child, node. insert. After – document. write, … – Event handlers in HTML, e. g. <…onclick=“javascript: xyz(…)”> 1. Parse partial DOM tree/HTML 2. Execute scripts in the sandbox environment 25
Dynamic script loading in Java. Script • Example from Google Maps 26
Different parsing techniques • Via a sandboxed iframe 1. Create sandbox iframe 2. Set content via srcdoc attribute – Better performance – Parsed exactly as will be interpreted by browser – Executed asynchronously • (Alternative) Via a HTML parsing library in Java. Script 27
Loading additional code in the sandbox • External code needs to be executed in a previously set up sandbox – Loading API + glue code – Dynamic script loading • Two new operations: – inner. Eval(code) – inner. Load. Script(url) 28
Case studies • Single principal code • Multiple-principal code – Context-aware ads 29
Implementation challenges • Legacy scripts need additional preprocessing to be compatible with the framework – Secure ECMAScript restrictions • A subset of ECMAScritp strict mode • Global variables aliased as window properties • No ‘this’ auto coercion 30
JS transformation examples 31
Summary – A client-side Java. Script architecture for untrusted Java. Script • Only using libraries and wrappers – Complete mediation using Secure ECMAScript • DOM node operations • Java. Script APIs – Backward compatibility • No browser modifications • Direct script delivery to the browser • Support for legacy scripts 32
Thank you! 33
- Slides: 33
