A Two-Tier Sandbox Architecture for Untrusted JavaScript

Phu H. PhungChalmers University of Technology

JSTools’ 12June 13, 2012, Beijing, China

Joint work with Lieven Desmet (KU Leuven)

2

Untrusted JavaScript

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

3

Approaches for untrusted JavaScript

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

Lightweight Self-

Protecting JavaScript

4

Outline

Context Overview of Self-Protecting

JavaScript Goals Two-tier sandbox architecture Technical approach Validation Summary and further work

5

Lightweight Self-Protecting JavaScript (SPJS)

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

6

Advantages of SPJS

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

7

SPJS with Untrusted JavaScript

Self-Protecting JavaScript Code TRUSTED

UNTRUSTED

No privilege distinguish between hosting code and external code

Hosting codeHosting

codeHosting

code

external code

external code

8

Goals

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

9

Sandboxing untrusted code

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 APIvar api = {...}; //constructingvar makeSandbox = cajaVM.compileModule(untrustedCodeSrc);var sandboxed = makeSandbox(api);

10

Policy definition approaches 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

Policy code within API code

API/policy 2API/policy 1

untrusted

API/policy 3

untrusted

untrusted

• API implementation is complex,

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

11/40

12

Two-tier sandbox architecturevar 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 environme

nt, e.g. the

DOM

The policy code can only access the base-line API and provided

wrapper functions (ensuring no leaks to

global)The untrusted code can only access objects returned by the enforcement sandbox

The implementation of policy is an

adaptation of Self-Protecting JavaScript

in ECMAScript 5 (solved the issues of Mozilla-specific features such as delete problem, getter, setter)

14

The architecture in multiple-principal untrusted code

Policy 2Policy 1

untrusted

Policy 3

untrusted

untrusted

Base-line API implementation,in e.g. `api.js’ file

15

Additional advantages

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

16

Challenges & technical approach

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

17

Validation

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

18

Summary and further work

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

19

Sponsors

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

20

THANK YOU!

21

Backup slides

22

Mediation

alert implementation

JavaScript execution environment(e.g. browsers)Native implementations

code pointers User functions

alert(‘Hi!’) window.alert

alert wrapper(+policy code)

Attacker codealert = function(){...};

alert wrapper

unique

(enforced by SPJS)

23

Base-line API and application-specific policiesvar 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){} },

//…}

var iDocument = new iHTMLDocument(); //base-linevar mydocument = enforceWhitelistPolicies(my_policy, iDocument);var api = {document: mydocument, …};

Application-specific policies

24

A case studyM

en

u a

nd

oth

er

con

ten

ts:

no a

ccess

to

ad

scr

ipt

Allow restricted read access to the ad script

Allow restricted write access to the ad script

ad.js

Sandbox policy.j

s

api.js

25

Deployment example

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?

26

Wrappers

Wrap method callsbuiltin’ = builtinbuiltin = function(){ policy_check?

builtin’:null }

Property accesses__defineGetter__(…)__defineSetter__(…)

Built-in call

Built-in

Safewrapp

erPolicy

27

Policy examples

Only allow URI in a white-list when sending by XMLHttpRequestwrap(XMLHttpRequest, whitelist_policy)

Do not allow send after cookie readdocument.__defineGetter__(‘cookie’,

cookie_policy) Limit the number of alerts to 2

wrap(window.alert, alert_policy)

28

Deployment illustration<html> <head> <script src=“selfprotectingJS.js"></script> <title>Self-protecting JavaScript </title> <meta content=…> <style>…</style> <script>…</script> <!-- more heading setting --> </head> <body> <script type="text/javascript"> (function() {..})(); </script> <!-- the content of page --> </body></html>

Policy code and

enforcement code defined in a text file

The enforcement code can be

deployed anywhere: server side, proxy or browser plug-in, i.e.

no need for a modified browser

The orgininal

code is not syntactically modified

6.33

66.03

0

10

20

30

40

50

60

70

Self-Protecting BrowserShield

Slo

wd

ow

n (t

imes

)

Runtime overhead

29

Tamper-proof issues

Wrapping library + policy code

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

Anonymous scope

Function• constructor• prototype • apply( )

• call( )

$virgin_apply = Function.prototype.apply;

inheritanceThis is a

general JavaScript problem

30

Non-declarative argument issue

open implementation

JavaScript execution environment(e.g. browsers)Native implementations

code Policy checkerwindow.open("good.com","_blank","location=yes",true); Policy:

Only allow URL in awhitelist

var maliciousURL = {toString: function() { this.toString = function(){ return "bad.com"}; return "good.com"; }}window.open(maliciousURL);

good.com,..

good.com

Time of check

Time of use

bad.com

good.com,..

31

WRAPPER

Declarative policies

CopyCombin

e

Policy

Built-in

x: {…}y:"_blank"z: "location=false" w:true

x: "string"y: *z: "string"w: "boolean"

x: "good.com"z: "location=false"w:true

x: "good.com"z: "location=true"w: false

x: "good.com"y:"_blank"z: "location=true"w:false

Copy values and coerce to the type specified by the policy

Policy can inspect and modify values

The output of the policy is

merged with the original input

x = {toString: function() { this.toString = function(){ return " bad.com"}; return "good.com";}}

Inspection type for policy

32

Self-Protecting JavaScript revisited

Self-Protecting JavaScript Code TRUSTED

UNTRUSTED

Self-protecting JavaScript is appealing for untrusted dynamic loaded JavaScript does not parse or transform the code, and can enforce application-specific, modular

fine-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…

33

ECMAScript 5 (ES5)

Patch dangerous features in current JavaScript

ES5 strict mode (ES5S) provides more restrictions

Credit: Taly at el, SP2011

34

ES5 strict mode to SecureECMAScript

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

35

Sandboxing untrusted code in SecureECMAScript 5 (Caja team)

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);

APIGlobal context

untrustedCode

sandbox

36

Summary

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