Lightweight Self-Protecting JavaScript

ACM Symposium on Information, Computer
Communication Security (ASIACCS 2009)
10 - 12 March 2009, Sydney, Australia
Lightweight Self-Protecting JavaScript
Phu H. Phung David Sands
Chalmers University of Technology
Gothenburg, Sweden
Andrey Chudnov
Stevens Institute of Technology
New Jersey, USA

2/18
The problem
• Injected (untrusted) JavaScript code
– A malicious user (the attacker) injects
potentially dangerous JavaScript code into a
webpage via data entry in the webpage, e.g.:
• blog
• forum
• web-mail
• Third party scripts (e.g. advertisement,
mashup web applications)
• Buggy code
Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009

Yamanner (2006)
• Exploiting the Javascript
onload event handler
(once the email is
opened)
Attack examples
Samy (2005)
• A malicious user injects
executable code in a
HTML tag
<div style="BACKGROUND:
url('java
script:eval(……)')">
</div>
Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009 3/18

4/18
Previous solutions
Server Filtering for Script Detection
• detect and remove potential malicious scripts
Problems
• Parser mismatch problem: filter does not always
parse in the same way as browser
c.f. Samy / MySpace
• Dynamic scripts problematic...

5/18
Previous solutions
<script>
document.write(‘<scr’);
document.write(‘ipt> malic’);
var i= 1;
document.write(‘ious code; </sc’);
document.write(‘ript>’);
</script>
detect and remove potential malicious scripts
Problems
Parser mismatch problem: filter does not always
parse in the same way as browser
c.f. Samy / MySpace, Yamanner / Yahoo Mail
<script> malicious code; </script>
• Dynamic scripts problematic...

6/18
Previous solutions
Prevent dynamic scripts by safe language subsets
(c.f. Facebook’s FBJS, Adsafe, CoreScript)
• Limits functionality
• Defeated by parser mismatch problem

• Dynamic code
runtime transformation
high overhead
7/18
Previous solutions
Behavioural Control:
Don’t try to detect bad scripts,
just prevent bad behaviour
• Modify browser with
reference monitor
• Transform code at
runtime to make it safe
• Requires
browser
modification
• Limited policies
e.g. BEEP
• Parser mismatch
problem

Our approach: Use an IRM
• “inline” the policy into the JavaScript code
so that the code becomes self-protecting
• The policy enforcement is implemented in
a lightweight manner
– does not require browser modification
– non invasive: the original code (and any dynamically
generated code) is not syntactically modified
– its implementation is a small and simple adaptation of
an aspect-oriented programming library

The policy
• The enforcement mechanism is security
reference monitor-based
• Ensure safety property of program execution
• Examples:
• Only allow URI in a whitelist when sending by
XMLHttpRequest
• Do not allow send after cookie read
• Limit the number of alerts to 2

Enforcement method
• Intercepts JavaScript API method call by
inlining policy into the call
– control or modify the bad behaviour
• Consider the behaviour of the code
– Avoid the problems of dynamic feature of
JavaScript

Execution point =
Point cut in AOP
11/18
• Use aspect-oriented programming (AOP)
to intercept JavaScript API method call
before( {target: window, method: 'alert'},
function() {
log('AOP test: window.alert is invoked');
}
);
• No browser modification
• No syntactical script code modification
Advice
(additional code at an
execution point)
Lightweight
Advice types:
before, after, around

JavaScript execution environment
(e.g. browsers)
12/18
Enforcement method
Native implementations
alert
implementation
code pointers User
functions
alert(..) window.alert
unique
alert
wrapper
(+policy code)
Attacker code
alert =
function(){...};
alert
wrapper

A realisation
• Structure of a webpage containing policy
enforcement code
• Policies are located in the first script tag
– Policy enforcement is applied for the rest of
code

Effectiveness
• Defend real-world exploits
– phpBB 2.0.18 vulnerabilities
– WebCal vulnerabilities
• Can enforce application-specific policies
– Using building blocks, i.e. security policy
patterns

Security Policy Patterns
• Preventing leakage of sensitive data
– monitoring sensitive data read and data output e.g.
write, redirect, XMLHttpRequest...
• Preventing impersonation attacks
– only allow URI in a defined white-list
• Preventing forgery attacks, e.g. open a new
window without the location bar
– enforce corresponding invariants
• Preventing resource abuse
– limit or prohibit potential abuse functions

Overhead
Weaving overhead
66,03
6,33
70
60
50
40
30
20
10
0
Self-Protecting BrowserShield
Slowdown (times)
Code transformation
[Reis, C. et al, 2007]
Render: 5.37%
Weaving slowdown
6,33 times
(We measure
micro-benchmark
with operations)

17/18
Limitations
• Policies cannot span multiple pages
– frame and iframe are separate pages!
• Implementation Specific Solutions and
Problems
– Use of custom getter and setter (in Mozilla,
but not in IE)
– Problems handling Mozilla’s delete semantics
Both problems solved in ECMA-262 v3.1
proposal

18/18
Conclusions
• Our approach is to control and modify the
behaviour of JavaScript by transforming
the code to make it self-protecting
– no browser modifications
– non-invasive, avoiding the need for extensive
runtime code transformation
• The enforcement code can be deployed in
any sides: server side, proxy or plug-in.

20/18
Previous solutions (cont.)
• Code transformation: modifies
JavaScript code before executing it
Example of BrowserShield [Reis, C. et al,
ACM Trans. Web, 1(3):11, 2007]

Lightweight Self-Protecting JavaScript

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (14)

Ähnlich wie Lightweight Self-Protecting JavaScript

Ähnlich wie Lightweight Self-Protecting JavaScript (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Lightweight Self-Protecting JavaScript