A Two-Tier Sandbox Architecture for Untrusted JavaScript

1. Phu H. Phung Chalmers University of Technology A Two-Tier Sandbox Architecture for Untrusted JavaScript • Joint work with LievenDesmet (KU Leuven) JSTools’ 12 June 13, 2012, Beijing, China

2. Untrusted JavaScript • External third-party JS code embedded to hosting pages, e.g., ads, widgets, analysis tools • 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

3. Approaches for untrusted JavaScript • Server-side pre-processing of untrusted code to ensure the code is in a safe subset • Transformation, e.g. Caja, BrowserSheild • Code validation, e.g. Adsafe • Iframe isolation • e.g., Adjail, Webjail • Behavioral sandboxing • Browser modification, e.g. ConScript • Client-side security wrappers Lightweight Self-Protecting JavaScript

4. Outline • Context • Overview of Self-Protecting JavaScript • Goals • Two-tier sandbox architecture • Technical approach • Validation • Summary and further work

5. Lightweight Self-Protecting JavaScript (SPJS) • Intercept JavaScript security-relevant actions with policies by wrappers • control or modify the bad behaviour • The method works since we only try tocontrol built-in calls

6. Advantages of SPJS • Easy of deployment • No browser modification nor user installation • Non-invasive: no difficulties with dynamic-generated JavaScript code • Focus on code behavior, not code integrity • does not parse or transform the code • Can enforce application-specific, fine-grained policies at runtime, e.g.: • limit the number of popup to 3 • Disallow send after cookie read

7. SPJS with Untrusted JavaScript Self-Protecting JavaScript Code • No privilege distinguish between hosting code and external code TRUSTED Hosting code UNTRUSTED Hosting code Hosting code external code external code

8. Goals • Deploy SPJS in the context of untrusted JS • Load and execute untrusted code without pre-processing the code • No browser modification is required • Enforce modular and fined-grained, stateful security policies for a piece of untrusted code • Protect the hosting page from untrusted code • Robust to potential flaws in security policies • Bad written policies might not break security

9. Sandboxing untrusted code • Use Secure ECMAScript (SES) library developed by Google Caja team (Miller et al) • Load a piece of code to execute within an isolated environment • The code can only interact with the outside world via a provided API var api = {...}; //constructingvar makeSandbox = cajaVM.compileModule(untrustedCodeSrc);var sandboxed = makeSandbox(api);

10. Policy definition approaches • API implementation • Can enforce coarse-grained, generic policies, e.g.: • Sanitize HTML • Ensure complete mediation • More fine-grained policies are needed for multiple untrusted code • Modular, principal-specific, e.g.: script1 is allowed to read/write reg_A, script2 is allowed to read reg_A • Stafeful, e.g.: limit the number of popups to 3 • Cross-principal stateful policies, e.g: after script1 write to reg_A, disallow access from script2 to reg_A

11. Policy code within API code • API implementation is complex, • difficult and error-prone to specify application-specific policy within API API/policy2 API/policy 1 untrusted untrusted API/policy 3 untrusted

12. Two-tier sandbox architecture varapi = loadAPI(api_url); varouterSandbox = cajaVM.compileModule(policyCode); varenforcedAPI = outerSandbox(api); varinnerSandbox = cajaVM.compileModule(untrustedCode); innerSandbox(enforcedAPI);

13. The policy code can only access the base-line API and provided wrapper functions (ensuring no leaks to global) Base-line API implementation, in e.g. `api.js’ file Sandbox running policy code, defined in a separate file e.g. `policy.js’ The implementation of policy is an adaptation of Self-Protecting JavaScript in ECMAScript 5 (solved the issues of Mozilla-specific features such as delete problem, getter, setter) The untrusted code can only access objects returned by the enforcement sandbox Sandbox running untrusted code, defined in a separate file e.g. `untrusted.js’ JavaScript environment, e.g. the DOM

14. 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

15. Additional advantages • Policy definition is constrained by the outer-sandbox • Even bad written policies can only access the API, not the real DOM • Whitelist (least-privilege) implementation approach • Only properties and objects defined in policies are available to the untrusted code • Only define least-privilege policies to function

16. Challenges & technical approach • Load and run remote JS code • Server-side proxy + XMLHttpRequest • Base-line API implementation – complete mediation is essential • Proxy API in Harmony ECMAScript • Dynamic loaded code, e.g. document.write(‘<script …>…</script>’), … • Load and execute the script in the same scope

17. Validation • The prototype implementation is validated by a number of JS widgets and a context-sensitive web ad • On-going work • In real applications, e.g., Google Maps, Google Analytics, jQuery • Ad networks – advertisement-specific behaviors

18. Summary and further work • The two-tier sandbox architecture separates API implementation and policy definition • Load and execute a piece of untrusted code in a sandboxed environment controlled by fine-grained, stateful policy enforcement • Further work will focus on practical issues to deploy the architecture to real-world scenarios

19. Sponsors The work is partial funded by the European FP7 project WebSandhttp://www.websand.eu This talk, i.e. the trip, is supported the Ericsson Research Foundation With the financial support from the Prevention of and Fight against Crime Programme of the European Union

20. Thank you!