Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Phu H. PhungChalmers University of Technology            Joint work with Lieven Desmet (KU Leuven)                  JSTool...
   External third-party JS code embedded to    hosting pages, e.g., ads, widgets, analysis    tools     Run with the sam...
   Server-side pre-processing of untrusted code    to ensure the code is in a safe subset     Transformation, e.g. Caja,...
   Context   Overview of Self-Protecting JavaScript   Goals   Two-tier sandbox architecture   Technical approach   V...
 Intercept JavaScript security- relevant actions with policies by wrappers  control or modify the bad behaviour The met...
   Easy of deployment     No browser modification nor user installation   Non-invasive: no difficulties with dynamic-  ...
Self-Protecting                           TRUSTED  JavaScript CodeHosting code                          UNTRUSTED  Hosting...
   Deploy SPJS in the context of untrusted JS     Load and execute untrusted code without pre-      processing the code ...
   Use Secure ECMAScript (SES) library    developed by Google Caja team (Miller et al)     Load a piece of code to execu...
   API implementation     Can enforce coarse-grained, generic policies, e.g.:      ▪ Sanitize HTML      ▪ Ensure complet...
API/policy 1     • API implementation is complex,                                      API/policy 2                    • d...
var api = loadAPI(api_url);var outerSandbox =     cajaVM.compileModule(policyCode);var enforcedAPI = outerSandbox(api);var...
Base-line API             The policy code can only  implementation,         access the base-line API and  in e.g. `api.js’...
Base-line API           Policy 2Policy 1                       implementation,untrusted              in e.g. `api.js’ file...
   Policy definition is constrained by the outer-    sandbox     Even bad written policies can only access the API,     ...
   Load and run remote JS code     Server-side proxy + XMLHttpRequest   Base-line API implementation – complete    medi...
   The prototype implementation is validated    by a number of JS widgets and a context-    sensitive web ad   On-going ...
   The two-tier sandbox architecture separates    API implementation and policy definition   Load and execute a piece of...
The work is partial funded by the European FP7 project  WebSand http://www.websand.euThis talk, i.e. the trip, is supporte...
19
20
User           JavaScript execution environment   code                pointers                    (e.g. browsers)         ...
var node_map = WeakMap(); function iHTMLDocument(){ node_map.set(this,document); } iHTMLDocument.prototype ={        getEl...
Allow restricted read access   AllowMenu and otherno access to ad                  to the ad script               restrict...
var api_and_enforcement = ...//baseline API & enforcement libary//using XMLHtmlRequest to get the content of file//`policy...
Built-in             Safe                   Built-in                   wrapper call                    Policy    Wrap met...
   Only allow URI in a white-list when sending    by XMLHttpRequest    wrap(XMLHttpRequest, whitelist_policy)   Do not a...
<html>          Runtime overhead Policy code and                  <head>  enforcement                        <script src=“...
Function                              • constructor                              • prototype                              ...
code                             Policy checker        JavaScript execution environment                                   ...
WRAPPER                                   Policy can inspect and        Inspection                                modify v...
   Self-protecting JavaScript is appealing for      Self-Protecting                             TRUSTED    untrusted Code...
   Patch dangerous features in current    JavaScript   ES5 strict mode (ES5S) provides more    restrictions             ...
   SecureECMAScript (SES) is a subset of ES5S,    under consider to be included in future    ECMAScript     The Google C...
   Untrusted code executed in a sandbox can    only interact with the outside world through    a provided API    var modu...
   Our approach is to control and modify the    behaviour of JavaScript by wrapping the    security-sensitive operations ...
Upcoming SlideShare
Loading in …5
×

1

Share

Download to read offline

A Two-Tier Sandbox Architecture for Untrusted JavaScript

Download to read offline

JSTools'12 13 June, 2012 Beijing, China

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

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
  • BalamuruganRamar

    Jul. 3, 2013

JSTools'12 13 June, 2012 Beijing, China

Views

Total views

3,446

On Slideshare

0

From embeds

0

Number of embeds

26

Actions

Downloads

24

Shares

0

Comments

0

Likes

1

×