Your SlideShare is downloading. ×
0
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
A Two-Tier Sandbox Architecture for Untrusted JavaScript
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

A Two-Tier Sandbox Architecture for Untrusted JavaScript

1,571

Published on

JSTools'12 13 June, 2012 Beijing, China

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
1,571
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
14
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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
  • Transcript

    • 1. Phu H. PhungChalmers University of Technology Joint work with Lieven Desmet (KU Leuven) JSTools’ 12 June 13, 2012, Beijing, China
    • 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 TRUSTED JavaScript CodeHosting code UNTRUSTED Hosting code Hosting code  No privilege distinguish betweenexternal code hosting code and external code external code 6
    • 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 var api = {...}; //constructing var makeSandbox = cajaVM.compileModule(untrustedCodeSrc); var sandboxed = makeSandbox(api); 8
    • 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 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. var api = loadAPI(api_url);var outerSandbox = cajaVM.compileModule(policyCode);var enforcedAPI = outerSandbox(api);var innerSandbox = cajaVM.compileModule(untrustedCode);innerSandbox(enforcedAPI); 11
    • 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. Base-line API Policy 2Policy 1 implementation,untrusted in e.g. `api.js’ file untrusted Policy 3 untrusted 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(‘<script …>…</script>’), …  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.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. 19
    • 21. 20
    • 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. 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. 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. 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. 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.  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. <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. 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. 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. 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.  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.  Patch dangerous features in current JavaScript ES5 strict mode (ES5S) provides more restrictions Credit: Taly at el, SP201132
    • 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.  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.  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

    ×