1. Phu H. Phung Chalmers University of Technology JSTools’ 12 June 13, 2012, Beijing, China Joint work with Lieven Desmet (KU Leuven)

2.  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 1

3.  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 2

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

5.  Intercept JavaScript security- relevant actions with policies by wrappers  control or modify the bad behaviour  The method works since we only try to control built-in calls 4

6.  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 5

7. Self-Protecting JavaScript Code TRUSTED UNTRUSTED 6  No privilege distinguish between hosting code and external code Hosting code external code

8.  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 7

9.  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 8 var api = {...}; //constructing var makeSandbox = cajaVM.compileModule(untrustedCodeSrc); var sandboxed = makeSandbox(api);

10.  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 9

11. API/policy 2 API/policy 1 untrusted API/policy 3 untrusted API implementation is complex, difficult and error-prone to specify application-specific policy within API 10/40

12. 11 var api = loadAPI(api_url); var outerSandbox = cajaVM.compileModule(policyCode); var enforcedAPI = outerSandbox(api); var innerSandbox = cajaVM.compileModule(untrustedCode); innerSandbox(enforcedAPI);

13. Sandbox running untrusted code, defined in a separate file e.g. `untrusted.js’ Sandbox running policy code, defined in a separate file e.g. `policy.js’ Base-line API implementation, in e.g. `api.js’ file JavaScript environment, e.g. the DOM The untrusted code can only access objects returned by the enforcement sandbox 12

14. Policy 2 Policy 1 untrusted Policy 3 untrusted Base-line API implementation, in e.g. `api.js’ file 13

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

16.  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(‘ … ’), …  Load and execute the script in the same scope 15

17.  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 16

18.  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 17

19. The work is partial funded by the European FP7 project WebSand http://www.websand.euhttp://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 18

20. 19