Lightweight self-protecting JavaScript

This paper introduces a method to control JavaScript execution. The aim is to prevent or modify inappropriate behaviour caused by e.g. malicious injected scripts or poorly designed third-party code. The approach is based on modifying the code so as to make it self-protecting: the protection mechanism (security policy) is embedded into the code itself and intercepts security relevant API calls. The challenges come from the nature of the JavaScript language: any variables in the scope of the program can be redefined, and code can be created and run on-the-fly. This creates potential problems, respectively, for tamper-proofing the protection mechanism, and for ensuring that no security relevant events bypass the protection. Unlike previous approaches to instrument and monitor JavaScript to enforce or adjust behaviour, the solution we propose is lightweight in that (i) it does not require a modified browser, and (ii) it does not require any run-time parsing and transformation of code (including dynamically generated code). As a result, the method has low run-time overhead compared to other methods satisfying (i), and the lack of need for browser modifications means that the policy can even be applied on the server to mitigate some effects of cross-site scripting bugs.

[1]  Fred B. Schneider,et al.  Enforceable security policies , 2000, TSEC.

[2]  Lujo Bauer,et al.  Composing security policies with polymer , 2005, PLDI '05.

[3]  James P Anderson,et al.  Computer Security Technology Planning Study , 1972 .

[4]  Michael Hicks,et al.  Defeating script injection attacks with browser-enforced embedded policies , 2007, WWW '07.

[5]  Úlfar Erlingsson,et al.  The Inlined Reference Monitor Approach to Security Policy Enforcement , 2004 .

[6]  Úlfar Erlingsson,et al.  IRM enforcement of Java stack inspection , 2000, Proceeding 2000 IEEE Symposium on Security and Privacy. S&P 2000.

[7]  Steven D. Gribble,et al.  A safety-oriented platform for Web applications , 2006, 2006 IEEE Symposium on Security and Privacy (S&P'06).

[8]  Helen J. Wang,et al.  BrowserShield: vulnerability-driven filtering of dynamic HTML , 2006, OSDI '06.

[9]  Elias Levy,et al.  Worst-Case Scenario , 2006, IEEE Security & Privacy.

[10]  Fred B. Schneider,et al.  A Language-Based Approach to Security , 2001, Informatics.

[11]  Gregor Kiczales,et al.  Aspect-oriented programming , 2001, ESEC/FSE-9.

[12]  Alexander Aiken,et al.  Static Detection of Security Vulnerabilities in Scripting Languages , 2006, USENIX Security Symposium.

[13]  Ankur Taly,et al.  An Operational Semantics for JavaScript , 2008, APLAS.

[14]  Christopher Krügel,et al.  Pixy: a static analysis tool for detecting Web application vulnerabilities , 2006, 2006 IEEE Symposium on Security and Privacy (S&P'06).

[15]  Tadeusz Pietraszek,et al.  Defending Against Injection Attacks Through Context-Sensitive String Evaluation , 2005, RAID.

[16]  Cristina V. Lopes,et al.  Aspect-oriented programming , 1999, ECOOP Workshops.

[17]  Dilian Gurov,et al.  Provably correct runtime monitoring , 2008, J. Log. Algebraic Methods Program..

[18]  Lujo Bauer,et al.  Edit automata: enforcement mechanisms for run-time security policies , 2005, International Journal of Information Security.

[19]  Anh Nguyen-Tuong,et al.  Automatically Hardening Web Applications Using Precise Tainting , 2005, SEC.

[20]  Robert Wahbe,et al.  Efficient software-based fault isolation , 1994, SOSP '93.

[21]  Úlfar Erlingsson,et al.  End-to-End Web Application Security , 2007, HotOS.

[22]  Giovanni Vigna,et al.  Detecting malicious JavaScript code in Mozilla , 2005, 10th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS'05).

[23]  Ajay Chander,et al.  JavaScript instrumentation for browser security , 2007, POPL '07.

[24]  Christopher Krügel,et al.  Cross Site Scripting Prevention with Dynamic Data Tainting and Static Analysis , 2007, NDSS.