web security: securing untrusted web content in browsers
Post on 17-Dec-2014
119 Views
Preview:
DESCRIPTION
TRANSCRIPT
Web security: Securing untrusted web content at
browsers
Phu H. PhungUniversity of Illinois at Chicago
ACM Chicago Chapter seminarSeptember 10, 2014
Loyola University ChicagoComputer Science Department
2
Web page is rendered at browsers
• Web pages contain JavaScript code, a scripting language run at browsers
• JavaScript can provide a lot of functionalities rich interactions
92% of all websites use JavaScript [w3techs.com]
3
“88.45% of the Alexa top 10,000 web sites included at least one remote JavaScript
library”CCS’12
Web-based mobile applications
• HTML5 + JavaScript is a new trend for mobile developerso Cross-platform development,
“Write one run everywhere”
4
Third-party JavaScript is everywhere
• Advertisementso Adhese ad network
• Social webo Facebook Connecto Google+o Twittero Feedsburner
• Trackingo Scorecardresearch
• Web Analyticso Yahoo! Web
Analyticso Google Analytics
• …
5
Two basic composition techniques
• Iframe integration
6
<html><body>…<iframe src=“http://3rdparty.com/frame.html”></iframe>…</body></html>
3rd party
7
Two basic composition techniques
<html><body>…<script src=“http://3rdparty.com/script.js”></script>…</body></html>
3rd party
Script inclusion
Third-party JavaScript issues
• Third-party script inclusion run with the same privilege of the hosting page.
• Security issues:oMalicious third-party codeo Trusted third-party is compromised oConfidentiality, integrity, and other
security risks
8
9
Difficult issues with JavaScript
• JavaScript is a powerful language, but the language design is bad for security, e.g.:o Dynamic scripts: document.write, eval, ...o Encapsulation leakageo ...
<script> document.write(‘<scr’);document.write(‘ipt> malic’);var i= 1;document.write(‘ious code; </sc’);document.write(‘ript>’);</script>
<script> malicious code; </script>
A lot of attacks were
launched in practice
10
Samy attack on Myspace
• MySpace tries to filter out JavaScript code in user data
• BUT: The malicious code was injected in a “strange” way that escapes the filter
<div id=mycode style="BACKGROUND: url('java script:eval(document.all.mycode.expr)')" expr="var B=String.fromCharCode(34);………">
</div>
Another real world attack
• Million Browser Botnet (July 2013)
o Leverage Advertising Networks using JavaScript to launch Application-Level DDoS
o Paid on 2 ad networks for displaying treacherous advertisements on pages visited by hundreds of thousands of people
(Malicious code run automatically without user knowledge)
11
Jeremiah Grossman & Matt JohansenWhiteHat SECURITY
A recent attack on Reuter homepage (June 2014)
12
• Reuters website was compromised by the Syrian Electronic Armyo By code injection via a compromised third
party ad network.
13
State-of-the-art
• Limit third-party code to safe subset of JavaScripto Facebook JS, ADSafe, ADSafety, ...
• Browser-based sandboxing solutionso ConScript, WebJail, Contego, ...
• Server-side transformations of scripts to be includedo Google Caja, BrowserShield, ...
No compatibility with existing scripts
Browser modifications imply short-term deployment issues
No direct script delivery to browserGreat runtime overhead
Our approachLightweight Self-Protecting
JavaScript
• A behavioral sandbox model for JavaScriptoUsing only JS libraries and wrappersoNo browser modification is required o The JS code is keep in originalo Easily dealing with dynamic features of
JavaScript
14
15
API call interception
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)
16
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
17
Effectiveness• Defend almost all of the known XSS attacker
vectorso 34 attack vectors over 38 successful attack
vectors
• Provide Security Policy Patterns to build realistic policies e.g. prevent the attack of Firesheep on Facebook
• Defend real-world exploitso phpBB 2.0.18 vulnerabilities – a stored XSS
attacko WebCal vulnerabilities –a reflected XSS attack
Lightweight Self-Protecting JavaScript
Lightweight Self-Protecting JavaScript
ASIACCS’09
Safe Wrappers and Sane Policies for Self-Protecting
JavaScriptAppSec Research ’10
19
SPJS with Untrusted JavaScript
• No privilege distinguish between hosting code and external code
Self-Protecting JavaScript Code TRUSTED
UNTRUSTEDHosting
codeHosting
codeHosting
code
external code
external code
20
Goals• Deploy SPJS in the context of untrusted JS
o Load and execute untrusted code without pre-processing the code
o No browser modification is required
• Enforce modular and fined-grained, stateful security policies for a piece of untrusted codeo Protect the hosting page from untrusted code
• Robust to potential flaws in security policieso Bad written policies might not break security
Two-tier Sandbox Architecture
21
Sandbox running
untrusted code, defined in a separate
file e.g. `untrusted.js’
Sandbox running policy code, defined in a separate JS 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 outer sandbox
22
Two-tier sandbox architecture
var api = loadAPI(…);
var outerSandbox = cajaVM.compileModule(policyCode);
var enforcedAPI = outerSandbox(api);
var innerSandbox = cajaVM.compileModule(untrustedCode);
innerSandbox(enforcedAPI);
23
The architecture in multiple-principal untrusted code
Policy 2Policy 1
untrusted
Policy 3
untrusted
untrusted
Base-line API implementationin e.g. `api.js’ file
24
Sandboxing untrusted code
• Use Secure ECMAScript (SES) library developed by Google Caja teamo 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 = {...}; //constructingvar makeSandbox = cajaVM.compileModule(untrustedCodeSrc);var sandboxed = makeSandbox(api);
Isolation technique: The SES library
Object-capability environment• Scripts can accesso Objects they create themselveso Objects explicitly handed to them
25
APIGlobal context
untrustedCode
sandbox
Isolation technique: The SES library
26
27
Policy definition
• Base-line APIs implementationo Can enforce coarse-grained, generic policies, e.g.:
• Sanitize HTML• Ensure complete mediation
• Fine-grained policies for multiple untrusted JavaScript codeo Modular, principal-specific, e.g.: script1 is allowed to
read/write reg_A, script2 is allowed to read reg_A o Stafeful, e.g.: limit the number of popups to 3 o Cross-principal stateful policies, e.g: after script1
write to reg_A, disallow access from script2 to reg_A
Base-line APIs implementation
• Create a Virtual DOMo Intercepting wrapper around real DOMo Consult security policy on each operationo Use Harmony Proxies to generically intercept
property accesses on objects
• Virtual DOM implementation uses the Membrane Patterno Wrap any object passed from DOM to sandbox
(return values)o Unwrap any object passed from sandbox to DOM
(arguments)28
Deployment model
• Untrusted code is loaded into a string variableo Using server-side proxy + XMLHttpRequest (to
overcome same origin policy)o CORS/UMP headers set by the script provider
29
<script src=“http://3rdparty.com/script.js”></script>
<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>
before
after
30
Secure dynamic script evaluation
• Special handlers to intercept all methods that allow script tags to be addedo node.appendChild, node.insertBefore,
node.replaceChild, node.insertAftero document.write, …o Event handlers in HTML, e.g. <…onclick=“javascript:xyz(…)”>
1. Parse partial DOM tree/HTML2. Execute scripts in the sandbox
environment
Case studies• Single principal code
• Multiple-principal codeo Context-aware ads
31
Two-tier Sandbox Architecture
A Two-tier Sandbox Architecture for
Untrusted JavaScript
JSTools’12 JSand: complete client-side sandboxing of
third-party JavaScript without browser
modificationsACSAC’12
A recent published workPhu H. Phung, Maliheh Monshizadeh, Meera Sridhar, Kevin W. Hamlen, and V.N. Venkatakrishnan. Between Worlds: Securing Mixed JavaScript/ActionScript Multi-party Web Content. IEEE Transactions on Dependable and Secure Computing (TDSC), forthcoming.
33
Thank you!
phu@cs.uic.edu
Extra slides
35
Wrapper example
36
Different parsing techniques
• Via a sandboxed iframe1. Create sandbox iframe2. Set content via srcdoc attributeo More performanceo Parsed exactly as will be interpreted by
browsero Executed asynchronously
• (Alternative) Via a HTML parsing library in JavaScript
37
38
Loading additional code in the sandbox
• Several use cases require external code to be executed in a previously set up sandboxo Loading API + glue codeoDynamic script loading
• Two new operations:o innerEval(code)o innerLoadScript(url)
top related