Lightweight Self-Protecting JavaScript

Lightweight Self-Protecting JavaScript

Phu H. Phung David SandsChalmers University of Technology

Gothenburg, Sweden

ACM Symposium on Information, Computer Communication Security (ASIACCS 2009)

10 - 12 March 2009, Sydney, Australia

Andrey ChudnovStevens 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

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

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

Yamanner (2006)• Exploiting the Javascript

onload event handler (once the email is opened)

Samy (2005)

• A malicious user injects executable code in a HTML tag <div style="BACKGROUND:

url('java script:eval(……)')">

</div>

Attack examples

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


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

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


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

• Limited policies e.g. BEEP

• Parser mismatch problem

• Dynamic code Þ runtime transformation Þ high overhead


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

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

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



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

0

10

20

30

40

50

60

70

Self-Protecting BrowserShield

Slo

wd

ow

n (

tim

es

)

Code transformation[Reis, C. et al, 2007]

Render: 5.37%

Weaving slowdown6,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 semanticsBoth 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 itExample of BrowserShield [Reis, C. et al,

ACM Trans. Web, 1(3):11, 2007]

Lightweight Self-Protecting JavaScript

Software

Transcript of Lightweight Self-Protecting JavaScript