Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Lightweight Self-Protecting JavaScript

Presented at the 4th International Symposium on Information, Computer, and Communications Security, ASIACCS 2009, Sydney, Australia, March 2009

More detail: http://www.cs.uic.edu/~phu/

  • Be the first to comment

  • Be the first to like this

Lightweight Self-Protecting JavaScript

  1. 1. 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. 2. 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
  3. 3. 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. 4. 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... Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009
  5. 5. 5/18 Previous solutions <script> document.write(‘<scr’); document.write(‘ipt> malic’); var i= 1; document.write(‘ious code; </sc’); document.write(‘ript>’); </script> 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, Yamanner / Yahoo Mail <script> malicious code; </script> • Dynamic scripts problematic... Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009
  6. 6. 6/18 Previous solutions Server Filtering for Script Detection Prevent dynamic scripts by safe language subsets (c.f. Facebook’s FBJS, Adsafe, CoreScript) • Limits functionality • Defeated by parser mismatch problem Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009
  7. 7. • 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 Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009
  8. 8. 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 Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009 8/18
  9. 9. 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 Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009 9/18
  10. 10. 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 Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009 10/18
  11. 11. 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 Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009 Advice (additional code at an execution point) Lightweight Advice types: before, after, around
  12. 12. 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 Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009
  13. 13. 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 Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009 13/18
  14. 14. 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 Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009 14/18
  15. 15. 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 Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009 15/18
  16. 16. 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) Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009 16/18
  17. 17. 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 Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009
  18. 18. 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. Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009
  19. 19. Phu H. Phung, David Sands, Andrey Chudnov – cse.chalmers.se ASIACCS'09, 10 March 2009
  20. 20. 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]

×