A Two-Tier Sandbox Architecture for Untrusted JavaScript

2,338 views
2,191 views

Published on

JSTools'12 13 June, 2012 Beijing, China

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,338
On SlideShare
0
From Embeds
0
Number of Embeds
26
Actions
Shares
0
Downloads
18
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Assume we have a base-line API implementation for untrusted code
  • Suppose that we have a policy only allow good URL defined in a whitelist
  • A Two-Tier Sandbox Architecture for Untrusted JavaScript

    1. 1. Phu H. PhungChalmers University of Technology Joint work with Lieven Desmet (KU Leuven) JSTools’ 12 June 13, 2012, Beijing, China
    2. 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. 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. 4.  Context Overview of Self-Protecting JavaScript Goals Two-tier sandbox architecture Technical approach Validation Summary and further work 3
    5. 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. 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. 7. Self-Protecting TRUSTED JavaScript CodeHosting code UNTRUSTED Hosting code Hosting code  No privilege distinguish betweenexternal code hosting code and external code external code 6
    8. 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. 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 var api = {...}; //constructing var makeSandbox = cajaVM.compileModule(untrustedCodeSrc); var sandboxed = makeSandbox(api); 8
    10. 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. 11. API/policy 1 • API implementation is complex, API/policy 2 • difficult and error-prone tountrusted specify application-specific policy within APIuntrusted API/policy 3 untrusted 10/40
    12. 12. var api = loadAPI(api_url);var outerSandbox = cajaVM.compileModule(policyCode);var enforcedAPI = outerSandbox(api);var innerSandbox = cajaVM.compileModule(untrustedCode);innerSandbox(enforcedAPI); 11
    13. 13. Base-line API The policy code can only implementation, access the base-line API and in e.g. `api.js’ file provided wrapper functionsSandbox running policycode, defined in a The implementation ofseparate file e.g. Thepolicy is ancode can only untrusted adaptation of`policy.js’ access objects returned by Self-Protecting JavaScript Sandbox running the enforcement sandbox in ECMAScript 5 untrusted code, defined in a separate file e.g. JavaScript `untrusted.js’ environment, e.g. the DOM 12
    14. 14. Base-line API Policy 2Policy 1 implementation,untrusted in e.g. `api.js’ file untrusted Policy 3 untrusted 13
    15. 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. 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(‘<script …>…</script>’), …  Load and execute the script in the same scope 15
    17. 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. 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. 19. The work is partial funded by the European FP7 project WebSand http://www.websand.euThis 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. 20. 19
    21. 21. 20
    22. 22. User JavaScript execution environment code pointers (e.g. browsers) functions Native implementations uniquealert(‘Hi!’) window.alert alert implementation alert (enforced by SPJS) wrapper (+policy code) alert wrapperAttacker codealert =function(){...}; 21
    23. 23. var node_map = WeakMap(); function iHTMLDocument(){ node_map.set(this,document); } iHTMLDocument.prototype ={ getElementById : function(id){ try{ element = node_map.get(this).getElementById(id); return wrapNode(element); }catch(e){} }, Application- //… specific } policiesvar iDocument = new iHTMLDocument(); //base-linevar mydocument = enforceWhitelistPolicies(my_policy, iDocument);var api = {document: mydocument, …}; 22
    24. 24. Allow restricted read access AllowMenu and otherno access to ad to the ad script restricted contents: script write access to the ad script api.js Sandbox policy.js ad.js 23
    25. 25. var api_and_enforcement = ...//baseline API & enforcement libary//using XMLHtmlRequest to get the content of file//`policy.js into `policyCode variablevar moduleMaker = cajaVM.compileModule(policyCode);var enforcedAPI = moduleMaker(api_and_enforcement);load_untrustedCode(enforcedAPI);function load_untrustedCode(api){ //using XMLHtmlRequest to get the content of file //`untrustedcode.js into `untrustedCode variable var moduleMaker = cajaVM.compileModule(untrustedCode); moduleMaker(api);} See it? 24
    26. 26. Built-in Safe Built-in wrapper call Policy  Wrap method calls  Property accesses builtin’ = builtin __defineGetter__(…) builtin = function(){ __defineSetter__(…) policy_check? builtin’:null } 25
    27. 27.  Only allow URI in a white-list when sending by XMLHttpRequest wrap(XMLHttpRequest, whitelist_policy) Do not allow send after cookie read document.__defineGetter__(‘cookie’, cookie_policy) Limit the number of alerts to 2 wrap(window.alert, alert_policy) 26
    28. 28. <html> Runtime overhead Policy code and <head> enforcement <script src=“selfprotectingJS.js"></script> 70 66.03 <title>Self-protecting JavaScript </title> code defined in The enforcement codeThetext file a orgininal <meta content=…> <style>…</style> 60 Slowdown (times) <script>…</script> can be deployed 50 code is not <!-- more heading setting --> </head> 40syntactically <body> 30 anywhere: server side, modified 20 proxy or browser plug- <script type="text/javascript"> (function() {..})(); 10 in, i.e. no need for a </script>6.33 <!-- the content of page --> </body> 0 modified browser </html> Self-Protecting BrowserShield 27
    29. 29. Function • constructor • prototype • apply( ) Anonymous scope • call( ) Wrapping library + policy code This is a general $virgin_apply = JavaScript problemFunction.prototype.apply;...original.apply(this,args);... 28
    30. 30. code Policy checker JavaScript execution environment (e.g. browsers)window.open("good.com","_blank","location=yes",true); Native implementations Policy: good.com,.. Only allow URL in a bad.com open whitelist implementation good.comvar maliciousURL ={toString: function() { this.toString = function(){ return "bad.com"}; return "good.com"; }}window.open(maliciousURL); 29
    31. 31. WRAPPER Policy can inspect and Inspection modify values type for policy x: "good.com" x: "good.com" x: "string" z: "location=true" z: "location=false" y: * w: false w:true z: "string" w: "boolean" Copy Combine Built-in x = {toString: function() { x: {…}Copy values and x: = function(){ The output of the this.toString "good.com" y:"_blank"the coerce to y:"_blank" return " bad.com"}; policy is merged with z: "location=false" type specified z: "location=true" return "good.com";} the original input w:true policy by the } w:false 30
    32. 32.  Self-protecting JavaScript is appealing for Self-Protecting TRUSTED untrusted Code JavaScript dynamic loaded JavaScript  does not parse or transform the code, and  can enforce application-specific, modular fine- UNTRUSTED grained policies at runtime However, due to the dangerous features of current JavaScript, it is not possible to sandbox untrusted JavaScript without heavy restrictions, e.g. FacebookJS, ADsafe… 31
    33. 33.  Patch dangerous features in current JavaScript ES5 strict mode (ES5S) provides more restrictions Credit: Taly at el, SP201132
    34. 34.  SecureECMAScript (SES) is a subset of ES5S, under consider to be included in future ECMAScript  The Google Caja team developed SES as an library In SES, untrusted JavaScript can be loaded and executed dynamically in an isolated environment  Without static validation, code filtering or transformation 33
    35. 35.  Untrusted code executed in a sandbox can only interact with the outside world through a provided API var moduleMaker = cajaVM.compileModule(untrustedCodeSrc); var sandboxed = moduleMaker(api); untrustedCode Global API context sandbox 34
    36. 36.  Our approach is to control and modify the behaviour of JavaScript by wrapping the security-sensitive operations to make the code self-protecting  no browser modifications  non-invasive ▪ solve the problem of dynamic scripts ▪ avoiding the need for extensive runtime code transformation Can apply in sandboxing untrusted JavaScript in ECMAScript 5 35

    ×