The document discusses self-protecting JavaScript as a technique for sandboxing untrusted third-party JavaScript code. It proposes a two-tier sandbox architecture where an outer sandbox enforces security policies on an API, and an inner sandbox then executes untrusted code using only the enforced API. This approach separates policy definition from API implementation to allow fine-grained, modular policies without requiring browser modifications or pre-processing of untrusted code. The technique works by wrapping security-sensitive JavaScript operations to intercept and control bad behavior based on the policies.

1. Phu H. Phung
Chalmers 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 Code
Hosting code
UNTRUSTED
Hosting code
Hosting code
 No privilege
distinguish between
external 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 to
untrusted
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 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

14. Base-line API Policy 2
Policy 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.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

20. 19

21. 20

22. 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

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
} policies
var iDocument = new iHTMLDocument(); //base-line
var mydocument =
enforceWhitelistPolicies(my_policy, iDocument);
var api = {document: mydocument, …}; 22

24. 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

25. 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

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 code
Thetext file
a orgininal
<meta content=…> <style>…</style>
60
Slowdown (times)
<script>…</script>
can be deployed
50
code is not <!-- more heading setting -->
</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
<!-- 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
problem
Function.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.com
var 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