A Two-Tier Sandbox Architecture for Untrusted JavaScript

Phu H. Phung
Chalmers University of Technology

Joint work with Lieven Desmet (KU Leuven)

JSTools’ 12
June 13, 2012, Beijing, China

 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

 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

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

3

 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

 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

Self-Protecting
TRUSTED
JavaScript Code

Hosting code
UNTRUSTED
Hosting code

Hosting code
 No privilege
distinguish between
external code
hosting code and
external code
external code
6

 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

 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

 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

API/policy 1 • API implementation is complex,
API/policy 2

• difficult and error-prone to
untrusted
specify application-specific
policy within APIuntrusted

API/policy 3

untrusted

10/40

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

11

Base-line API The policy code can only
implementation, access the base-line API and
in e.g. `api.js’ file provided wrapper functions
Sandbox running policy
code, defined in a The implementation of
separate 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

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

untrusted

Policy 3

untrusted

13

 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

 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

 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

 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

The work is partial funded by the European FP7 project
WebSand http://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

User JavaScript execution environment
code pointers (e.g. browsers)
functions
Native implementations

unique
alert(‘Hi!’) window.alert alert
implementation

alert (enforced by SPJS)
wrapper
(+policy code)

alert
wrapper

Attacker code
alert =
function(){...}; 21

Allow restricted read access Allow
Menu and other

no access to ad

to the ad script restricted
contents:

script

write access
to the ad
script

api.js
Sandbox
policy.js ad.js
23

var api_and_enforcement = ...//baseline API & enforcement libary
//using XMLHtmlRequest to get the content of file
//`policy.js' into `policyCode' variable
var 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

Built-in Safe
Built-in
wrapper
call
Policy

 Wrap method calls  Property accesses
builtin’ = builtin __defineGetter__(…)
builtin = function(){ __defineSetter__(…)
policy_check?
builtin’:null
}

25

 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

<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 code
Thetext file
a orgininal
<meta content=…> <style>…</style>
60

Slowdown (times)
<script>…</script>
can be deployed
50

code is not 
</head>
40

syntactically <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

</body>
0
modified browser
</html> Self-Protecting BrowserShield

27

Function
• constructor
• prototype
• apply( )
Anonymous scope • call( )
Wrapping library +
policy code This is a general
$virgin_apply = JavaScript
problem
Function.prototype.apply;

...
original.apply(this,args);
...
28

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.com
var maliciousURL =
{toString: function() {
this.toString = function(){
return "bad.com"};
return "good.com";
}
}
window.open(maliciousURL);
29

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

 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

 Patch dangerous features in current
JavaScript
 ES5 strict mode (ES5S) provides more
restrictions

Credit: Taly at el, SP201132

 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

 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

 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

A Two-Tier Sandbox Architecture for Untrusted JavaScript

More Related Content

Similar to A Two-Tier Sandbox Architecture for Untrusted JavaScript (20)

Recently uploaded (20)

A Two-Tier Sandbox Architecture for Untrusted JavaScript

Editor's Notes