Lightweight Self-Protecting JavaScript

Lightweight Self-Protecting JavaScript*
Phu H. Phung David Sands
Chalmers University of Technology
Gothenburg, Sweden
29.03.09 - 03.04.09, Dagstuhl Seminar 09141
Web Application Security
Dagstuhl 02 April 2009
Andrey Chudnov
Stevens Institute of Technology
New Jersey, USA
* In Proceedings of ASIACCS’09, 10-12 March 2009, Sydney, ACM Press

1/18
The concern problems
• Injected (untrusted) JavaScript code (e.g.XSS)
– 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
Dagstuhl 09141, 2 April 2009Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se

2/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...
Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se Dagstuhl 09141, 2 April 2009

3/18
Previous solutions
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
• Dynamic scripts problematic...
Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se
<script>
document.write(‘<scr’);
document.write(‘ipt> malic’);
var i= 1;
document.write(‘ious code; </sc’);
document.write(‘ript>’);
</script>
<script> malicious code; </script>
Dagstuhl 09141, 2 April 2009

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

5/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,
e.g. BEEP
• Limited policies
• Parser mismatch
problem
• Dynamic code
runtime transformation
high overhead
e.g. BrowserShield

6/18Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se
Our approach:
Use an Inlined Reference Monitor
• “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 white-list when sending by
XMLHttpRequest
• Do not allow send after cookie read
• Limit the number of alerts to 2

Enforcement method
• Intercept JavaScript API method call by
inlining policy into the call
– control or modify the bad behaviour
• Monitor access to sensitive properties

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

AOP weaving: Adapt jQuery AOP
Store the original method
Apply the policy
Control the original method
var wrap = function(pointcut, Policy) {
var source = (typeof(pointcut.target.prototype) != 'undefined‘)?
pointcut.target.prototype : pointcut.target;
var method = pointcut.method;
var original = source[method];
var aspect = function() {
var invocation = { object: this, args: arguments };
return Policy.apply(invocation.object,
[{ arguments: invocation.args,
method: method,
proceed : function(){ return original.apply(
invocation.object, invocation.args);}}] );
};
source[method] = aspect;
return aspect;
};

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

The problems of dynamic feature
• Consider the behaviour of the code
– Avoid the problems of dynamic feature of
JavaScript
%61%6C%65%72%74%28%27%58
%53%53%27%29%3B%0A%0A
alert(‘XSS’)
var abcxyz = window.alert;
abcxyz(‘XSS’);
eval(“alert(‘XSS’)”);
(function(){ return this;})().alert(‘XSS’);

13/18
• Use Mozilla-specific setter and getter*
object.prototype.__defineGetter__(...),
object.prototype.__defineSetter__(...)
* This feature is Mozilla-specific, however, it has been specified in the
current draft proposal for the next generations of JavaScript
(ECMA-262 3.1)
Monitoring Property access

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
The enforcement code can be deployed in
any sides: server side, proxy or plug-in

Effectiveness
• Defend real-world exploits
– phpBB 2.0.18 vulnerabilities – a stored XSS
attack (see demo)
– WebCal vulnerabilities –a reflected XSS attack
• Can enforce application-specific policies
– Using building blocks, i.e. security policy
patterns

Security Policy Patterns (1)
• Preventing leakage of sensitive data
– monitoring sensitive data read and data output e.g.
write, redirect, XMLHttpRequest...
enforcePolicy({target:XMLHttpRequest,
method: 'send'},
function(invocation){
XMLHttpRequestPolicy(invocation);});

• Preventing impersonation attacks
– only allow URI in a defined white-list
var XMLHttpRequestPolicy = function(invocation){
//allow the transaction if the
// URI is in the whitelist
if (AllowedURL(XMLHttpRequestURL)){
policylog("XMLHttpRequest is sent");
return invocation.proceed();
}
policylog("XMLHttpRequest is suppressed:“+
"potential impersonation attacks");
}

• Preventing forgery attacks, e.g.
– open a new window without the location bar: enforce
corresponding invariants
– faked links: detect and disable the faked links
var checkLinks = function(){
var links = document.links;
if (!links){ policylog('no links'); return; }
for(var i = 0; i < links.length; i++) {
if (!AllowedLinks(links[i].href))
{
links[i].href =
"javascript:alert('disabled link')";
}
}
}

• Preventing resource abuse
– limit or prohibit potential abuse functions

Overhead
Render: 5.37%
Weaving slowdown 6,33 times (We measure
micro-benchmark with operations)

21/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

22/18
Summary
• 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
• solve the problem of dynamic scripts
• avoiding the need for extensive runtime code
transformation

23/18
Further concerns
• Case studies for particular web
applications
• Integration with other methods
• Securing JavaScript AOP

ASIACCS'09, 10 March 2009Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se

25/18
Attacks to the Unique Reference Property
• Restoring built-in methods from another
page
– Creates a new window, frame or iframe to
manufacture a pointer to the original built-in
methods
• Mozilla’s delete operator
– Our wrapper methods are not built-in, they are
deletable and the deletion exposes the
original built-in.

Lightweight Self-Protecting JavaScript

Recommended

Recommended

More Related Content

Similar to Lightweight Self-Protecting JavaScript

Similar to Lightweight Self-Protecting JavaScript (20)

Recently uploaded

Recently uploaded (20)

Lightweight Self-Protecting JavaScript