Phu_APPSEC13 - OWASP Appsec USA 2013
Sandboxing JavaScript via Libraries and Wrappers
Phu H. Phung
University of Gothenburg, Sweden, and
University of Illinois at Chicago
About Me
• Receipt of international postdoc grant (3 years) by Swedish Research Council (VR), employed by Univ. of Gothenburg.
• Research Associate at UIC.
• PhD in Computer Science in 2011 from
Chalmers University, Sweden.
Hosted by OWASP & the NYC Chapter
• Selected research projects
– European WebSand (complete)
• End-to-end secure web framework
– Secure Web Advertisements, funded by NSF
(on-going)
– Defensive Optimizing Compiler, funded by
DARPA (on-going)
Hosted by OWASP & the NYC Chapter
This talk
• Based on the two published papers:
– PH Phung, L Desmet. A two-tier sandbox architecture for untrusted JavaScript , invited paper, JSTools’12.
– P Agten, S Van Acker, Y Brondsema, PH Phung, L
Desmet, F Piessens. JSand: complete client-side sandboxing of third-party JavaScript without browser modifications , ACSAC’12.
92% of all websites use JavaScript
[ w3techs.com
]
“88.45% of the Alexa top 10,000 web sites included at least one remote
JavaScript library”
CCS’12
5
• Advertisements
– Adhese ad network
• Social web
– Facebook Connect
– Google+
– Feedsburner
• Tracking
– Scorecardresearch
• Web Analytics
• …
– Yahoo! Web Analytics
– Google Analytics
Third-party JavaScript is everywhere
6
Iframe integration
<html><body>
…
<iframe src=“http://3rdparty.com/frame.html”>
</iframe>
…
</body></html>
Two basic composition techniques
3 rd party
7
Script inclusion
<html><body>
…
<script src=“http://3rdparty.com/script.js”>
</script>
…
</body></html>
Two basic composition techniques
3 rd party
8
Third-party JavaScript issues
• Third-party script inclusion 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
9
Difficult issues with JavaScript
• JavaScript is a powerful language, but the language design is bad for security, e.g.:
– Dynamic scripts: document.write, eval, ...
– Encapsulation leakage
– ...
A lot of
<script> document.
write(
attacks were
document.
write( ‘ipt> malic’ ); var i= 1;
launched in
document.
write( ‘ious code; </sc’ ); document.
write(
practice
</script>
<script> malicious code; </script>
10
Malicious third-party JavaScript example
The most reliable, cost effective method to inject evil code is to buy an ad.
Principles of Security. Douglas Crockford http://fromonesrc.com/blog/page/2/
An attack scenario
Million Browser Botnet
(July 2013)
– Leverage Advertising
Networks using JavaScript to launch Application-Level
DDoS Jeremiah Grossman & Matt Johansen
– Paid on 2 ad networks for displaying treacherous
WhiteHat SECURITY advertisements on pages visited by hundreds of thousands of people
– One day, got 13.6 million views of the ads, just spent less than $100
12
State-of-the-art
• Limit third-party code to safe subset of JavaScript
– Facebook JS, ADSafe, ADSafety, ...
No compatibility with existing scripts
• Browser-based sandboxing solutions
– ConScript, WebJail, Contego, ...
Browser modifications imply short-term deployment issues
• Server-side transformations of scripts to be included
– Google Caja, BrowserShield, ...
No direct script delivery to browser
Great runtime overhead
13
Our approach
• A sandbox model for third-party JavaScript
– Using only JS libraries and wrappers
– Whitelist (least-privilege) implementation approach
• Only properties and objects defined in policies are available to the untrusted code
– No browser modification is required
– The third-party code is keep in original
– Easily dealing with dynamic features of JavaScript
“Lightweight Self-Protecting JavaScript” , ASIACCS’09
14
Two-tier sandbox architecture
Base-line API implementation, in e.g. `api.js’ file
Sandbox running policy code, defined in a separate JS e.g. `policy.js’
The policy code can only access the base-line API and provided wrapper functions
Sandbox running untrusted code, defined in a separate file e.g.
`untrusted.js’
The untrusted code can only access objects returned by the outer sandbox
JavaScript environment, e.g. the DOM
15
Two-tier sandbox architecture var api = loadAPI(…); var outerSandbox = cajaVM.compileModule(policyCode); var enforcedAPI = outerSandbox(api); var innerSandbox = cajaVM.compileModule(untrustedCode); innerSandbox(enforcedAPI);
16
P olicy 1 untrusted
P olicy 3 untrusted
The architecture in multipleprincipal untrusted code
P olicy 2 Base-line API implementation, in e.g. `api.js’ file untrusted
17
Sandboxing untrusted code
• Use Secure ECMAScript (SES) library developed by Google Caja team
– Load a piece of code to execute within an isolated environment
• The code can only interact with the outside world via provided
APIs var api = {...}; //constructing var makeSandbox = cajaVM.compileModule(untrustedCodeSrc); var sandboxed = makeSandbox(api);
18
Isolation technique: The SES library
Object-capability environment
• Scripts can access
–
Objects they create themselves
– Objects explicitly handed to them
Global context
19
Isolation technique: The SES library
20
Base-line APIs implementation
• Create a Virtual DOM
– Intercepting wrapper around real DOM
– Use Harmony Proxies to generically intercept property accesses on objects
• Virtual DOM implementation uses the
Membrane Pattern
– Wrap any object passed from DOM to sandbox (return values)
– Unwrap any object passed from sandbox to DOM
(arguments)
21
Wrapper example
22
Policy definition
• Base-line APIs implementation
– Can enforce coarse-grained, generic policies, e.g.:
• Sanitize HTML
• Ensure complete mediation
• Fine-grained policies for multiple untrusted
JavaScript code
– Modular, principal-specific, e.g.: script1 is allowed to read/write elemt_A, script2 is allowed to read elemt_A
– Stafeful, e.g.: limit the number of popups to 3
– Cross-principal stateful policies, e.g: after script1 write to elemt_A, disallow access from script2 to elemt_A
23
Deployment model
• Untrusted code is loaded into a string variable
– Using server-side proxy + XMLHttpRequest (to overcome same origin policy)
– CORS (Cross-Origin Resource Sharing)
/UMP(Uniform Messaging Policy) headers set by the script provider
<script src=
“http://3rdparty.com/script.js”>
</script> before
<script src=“ses.js”></script>
<script src=“api.js”></script>
<script src=“policy0.js”></script>
<script> var script = get(“http://3rdparty.com/script.js”); ses.execute(script,policy0);
</script> after
24
Secure dynamic script evaluation
• Special handlers to intercept all methods that allow script tags to be added
– node.appendChild, node.insertBefore, node.replaceChild, node.insertAfter
– document.write, …
– Event handlers in HTML, e.g.
<…onclick=“javascript:xyz(…)”>
1. Parse partial DOM tree/HTML
2. Execute scripts in the sandbox environment
25
Dynamic script loading in
JavaScript
• Example from Google Maps
26
Different parsing techniques
• Via a sandboxed iframe
1. Create sandbox iframe
2. Set content via srcdoc attribute
– Better performance
– Parsed exactly as will be interpreted by browser
– Executed asynchronously
• (Alternative) Via a HTML parsing library in
JavaScript
27
Loading additional code in the sandbox
• External code needs to be executed in a previously set up sandbox
– Loading API + glue code
– Dynamic script loading
• Two new operations:
– innerEval(code)
– innerLoadScript(url)
28
• Single principal code
Case studies
• Multiple-principal code
– Context-aware ads
29
Implementation challenges
• Legacy scripts need additional preprocessing to be compatible with the framework
– Secure ECMAScript restrictions
• A subset of ECMAScritp strict mode
• Global variables aliased as window properties
• No ‘this’ auto coercion
30
JS transformation examples
31
Summary
– A client-side JavaScript architecture for untrusted JavaScript
• Only using libraries and wrappers
– Complete mediation using Secure
ECMAScript
•
DOM node operations
• JavaScript APIs
– Backward compatibility
•
No browser modifications
• Direct script delivery to the browser
• Support for legacy scripts
32
33
