330 likes | 341 Views
Explore the use of JavaScript libraries and wrappers to create a sandbox model for third-party JavaScript, without the need for browser modifications. This approach allows for secure execution of untrusted code without compromising integrity or confidentiality. Learn more about this two-tier sandbox architecture and its applications in various scenarios.
E N D
Sandboxing JavaScript 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. • PhD in Computer Science in 2011 from Chalmers University, Sweden. Hosted by OWASP & the NYC Chapter
Selected research projects • European WebSand(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 JavaScript, 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 JavaScript without browser modifications, ACSAC’12.
92% of all websites use JavaScript[w3techs.com] “88.45% of the Alexa top 10,000 web sites included at least one remote JavaScript library” CCS’12
Third-party JavaScript is everywhere • Advertisements • Adhese ad network • Social web • Facebook Connect • Google+ • Twitter • Feedsburner • Tracking • Scorecardresearch • Web Analytics • Yahoo! Web Analytics • Google Analytics • …
Two basic composition techniques Iframe integration <html><body> … <iframesrc=“http://3rdparty.com/frame.html”> </iframe> … </body></html> 3rd party
Two basic composition techniques Script inclusion <html><body> … <script src=“http://3rdparty.com/script.js”> </script> … </body></html> 3rd party
Third-party JavaScript 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
Difficult issues with JavaScript • JavaScript is a powerful language, but the language design is bad for security, e.g.: • Dynamic scripts: document.write, eval, ... • Encapsulation leakage • ... A lot of attacks were launched in practice <script> document.write(‘<scr’); document.write(‘ipt> malic’); var i= 1; document.write(‘ious code; </sc’); document.write(‘ript>’); </script> <script> malicious code; </script>
Malicious third-party JavaScript 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 MillionBrowserBotnet (July 2013) • Leverage Advertising Networks using JavaScript to launch Application-Level DDoS • 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 Jeremiah Grossman & Matt Johansen WhiteHat SECURITY
State-of-the-art • Limit third-party code to safe subset of JavaScript • Facebook JS, ADSafe, ADSafety, ... • Browser-based sandboxing solutions • ConScript, WebJail, Contego, ... • Server-side transformations of scripts to be included • Google Caja, BrowserShield, ... No compatibility with existing scripts Browser modifications imply short-term deployment issues No direct script delivery to browser Great runtime overhead
Our approach • A sandbox model for third-party JavaScript • 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 JavaScript “Lightweight Self-Protecting JavaScript”, ASIACCS’09
Two-tier sandbox architecture Base-line API implementation, in e.g. `api.js’ file The policy code can only access the base-line API and provided wrapper functions (ensuring no leaks to global) Sandbox running policy code, defined in a separate JS e.g. `policy.js’ The untrusted code can only access objectsreturned by the outersandbox Sandboxrunning untrusted code, defined in a separate file e.g. `untrusted.js’ JavaScript environment, e.g. the DOM
Two-tier sandbox architecture varapi = loadAPI(…); varouterSandbox = cajaVM.compileModule(policyCode); varenforcedAPI = outerSandbox(api); varinnerSandbox = cajaVM.compileModule(untrustedCode); innerSandbox(enforcedAPI);
The architecture in multiple-principal untrusted code • Base-line API implementation, • in e.g. `api.js’ file Policy 2 Policy 1 untrusted untrusted Policy 3 untrusted
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 = {...}; //constructingvar makeSandbox = cajaVM.compileModule(untrustedCodeSrc);var sandboxed = makeSandbox(api);
Isolation technique: The SES library Object-capability environment • Scripts can access • Objects they create themselves • Objects explicitly handed to them API Global context untrustedCode sandbox
Base-line APIs implementation • Create aVirtual 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)
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 JavaScript code • Modular, principal-specific, e.g.: script1 is allowed to read/write elemt_A, script2 is allowed to read elemt_A • Stafeful, e.g.: limit the number of popups to 3 • Cross-principal stateful policies, e.g: after script1 write to elemt_A, disallow access from script2 to elemt_A
Deployment model • Untrusted code is loaded into a string variable • Using server-side proxy + XMLHttpRequest (to overcome same origin policy) • CORS (Cross-Origin Resource Sharing) /UMP(Uniform Messaging Policy) headers set by the script provider <script src=“http://3rdparty.com/script.js”> </script> <script src=“ses.js”></script> <script src=“api.js”></script> <script src=“policy0.js”></script> <script>var script = get(“http://3rdparty.com/script.js”); ses.execute(script,policy0); </script> before after
Secure dynamic script evaluation • Special handlers to intercept all methods that allow script tags to be added • node.appendChild, node.insertBefore, node.replaceChild, node.insertAfter • document.write, … • Event handlers in HTML, e.g. <…onclick=“javascript:xyz(…)”> • Parse partial DOM tree/HTML • Execute scripts in the sandbox environment
Dynamic script loading in JavaScript • Example from Google Maps
Different parsing techniques • Via a sandboxed iframe • Create sandbox iframe • Set content via srcdoc attribute • Better performance • Parsed exactly as will be interpreted by browser • Executed asynchronously • (Alternative) Via a HTML parsing library in JavaScript
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: • innerEval(code) • innerLoadScript(url)
Case studies • Single principal code • Multiple-principal code • Context-aware ads
Implementation challenges • Legacy scripts need additional pre-processing to be compatible with the framework • Secure ECMAScriptrestrictions • A subset of ECMAScritp strict mode • Global variables aliased as window properties • No ‘this’ auto coercion
Summary • A client-side JavaScript architecture for untrusted JavaScript • Only using libraries and wrappers • Complete mediation using Secure ECMAScript • DOM node operations • JavaScript APIs • Backward compatibility • No browser modifications • Direct script delivery to the browser • Support for legacy scripts