lightweight self-protecting javascript

Lightweight Self-Protecting JavaScript*

Phu H. Phung David SandsChalmers University of Technology

Gothenburg, Sweden

29.03.09 - 03.04.09, Dagstuhl Seminar 09141

Web Application Security

Dagstuhl 02 April 2009

Andrey ChudnovStevens Institute of Technology

New Jersey, USA

* In Proceedings of ASIACCS’09, 10-12 March 2009, Sydney, ACM Press

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

3/18

Previous solutionsServer 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

4/18

Previous solutionsServer Filtering for Script Detectiondetect and remove potential malicious scripts

ProblemsParser mismatch problem: filter does not always

parse in the same way as browser

c.f. Samy / MySpace, Yamanner / Yahoo Mail

• Dynamic scripts problematic...


<script> document.write(‘<scr’);document.write(‘ipt> malic’);var i= 1;document.write(‘ious code; </sc’);document.write(‘ript>’);</script>

<script> malicious code; </script>


5/18

Previous solutionsServer Filtering for Script DetectionPrevent dynamic scripts by safe language subsets

(c.f. Facebook’s FBJS, ADsafe, CoreScript) • Limits functionality • Defeated by parser mismatch problem



6/18

Previous solutionsBehavioural 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


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


10/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;

};

12/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 codealert = 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’);

14/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)Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se

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


http://vinnova-sesame.org/jsstest/phpBB2/viewtopic.php?t=8


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



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


22/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 semanticsBoth problems solved in ECMA-262 v3.1

proposal



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



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

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

Software