Stanford Security Seminar, July 12, 2010, Stanford, CA, USA.

1. Stanford Security Seminar
July 12, 2010
Self-Protecting JavaScript:
A Lightweight Approach to Enforcing
Security Policies*
Phu H. Phung
Chalmers, Sweden
* This talk is based 2 joint papers with David Sands, Andrey Chudnov, Jonas Magazinius
appeared on ASIACCS’09 & OWASP AppSec’10

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

3. Difficult issues
• Parser mismatch problem:
– filter does not always parse in the same way as
browser
• Dynamic scripts problematic, e.g.
document.write, eval, ...
<script>
document.write(‘<scr’);
document.write(‘ipt> malic’);
var i= 1;
document.write(‘ious code; </sc’);
document.write(‘ript>’);
</script>
<script> malicious code; </script>

4. The landscape of JavaScript security
mechanisms
• Server filtering, but parser mismatch problem
• Language subset, sandboxing
• Behavioral sandboxing
– Code transformation
– No code transformation
• Browser modification
• No browser modification

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

6. The policies
• 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

7. Enforcement method
• Intercept JavaScript built-in method calls by
inlining policy into the call
– control or modify the bad behaviour
• Monitor access to sensitive properties

8. Enforcement method
JavaScript execution environment
(e.g. browsers)
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 Dagstuhl 09141, 2 April 2009

9. Implementation
• Use aspect-oriented programming (AOP) style
to intercept JavaScript API method calls
var wrapper = function(object, method, Policy) {
//...
var original = object[method];
var aspect = function() {
//...
return Policy.apply(...,
proceed : function(){
return original.apply(...)
});
};
object[method] = aspect;
return aspect;
};

10. Monitoring Property access
• Use the setter and getter
object.prototype.__defineGetter__(...),
object.prototype.__defineSetter__(...)
• Property: even can redefine setter/getter,
original wrapped properties are still protected

11. Deployment
• 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
Dagstuhl 09141, 2 April 2009

12. Secure the wrapper
• There are several issues that an attacker can
exploit the wrapper
– Function and Object Subversion
• Modifying the Function/ Object –prototype
– Global setter subversion
– Recover the wrapped built-in using aliases
• Static aliases
• Dynamic aliases

13. Function and Object Subversion
Object
• prototype • valueOf( )
Function
• constructor
• prototype
• apply( )
• call( )
{function instance}
• constructor
Modifying subverts
expected behavior
Wrapper:
original.apply(this,args)
Attack code:
var org;
Function.prototype.apply =
function(){ org = this}
Fixing :
original.apply= $virgin_apply

14. Global Setter subversion
Wrapper code
policy({args:
arguments,
proceed: original})
Subversion
var org;
Object.prototype.
__defineSetter__(‘proceed’,
function(o) { org = o });
Fixing the wrapper:
• No temporary objects?
• Use “safe” objects…
• Change JavaScript: Don’t execute setters upon
instantiation (IE, Firefox)

15. Static aliases
window.alert
alert
Window.prototype.alert
window.window.alert
window.__proto__.alert constructor.prototype.alert

16. Dynamic aliases
alert alert
wrapper
alert
We provide pre-defined policies which enforce methods
that possible return a window object with the same
policies as the current window

17. Sane Policies
• Object and Function Subversion in Policies
• Non Declarative Arguments

18. Function and Object Subversion in
Policies
Policy code
var whitelist =
{"good.com":true,
"good2.org":true}
if(whitelist[
address.substr(...))])
Fixing subversion
• hasLocalProperty()
• Use “safe” objects…
Subversion
Object.prototype[‘evil.com’]=true;*
String.prototype.substr =
function(){ return ‘good.com’}
The policy writer should not have
to remember this…
Credit: Meyerovich at el, WWW’10

19. “Safe” objects
• safe() function
– Creates a blank object which does not inherit
from the prototype-chain
• {__proto__: null}
– Recursively copies all fields from the input object
to the newly created copy

20. Non-declarative vs. declarative policies
Policy code
if
(whitelist[address])
img.src = address;
Fixing problem
Policy declare which types it
expects in a type language and
monitor enforces it
Attack
x = {toString: function() {
this.toString=
function()’bad.com’;
return ‘good.com’;
}
}

21. Types for Declarative Arguments
argument array cloning by type:
policy.toString(b) === ’xyz’
inspection type
? ‘string’
a b c
? ‘xyz’
original argument array
Computation by policy code
leading to call to
invocation.proceed()
inspection
argument array
policy’s modified
argument array
? ‘xy’ 42
Recombine with
original argument
and pass to
original built-in
a ‘xy’ 42
policy function proceed function
Example policy computation for some built-in called with (a,b,c). In
this example the policy inspects b at type string and removes the
last character, and sets the third parameter to 42 before calling
proceed() in order to access the original built-in function. In the
diagram ? is an abbreviation for undefined, and array objects are
depicted as boxes.

22. 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
• Possible vulnerabilities of the library are
addressed and fixed
• Typing for arguments to prevent
Dagstuhl 09141, 2 April 2009

23. References
• Jonas Magazinius, Phu H. Phung, and David
Sands (2010). Safe Wrappers and Sane Policies
for Self Protecting JavaScript. OWASP AppSec
Research 2010, June 2010.
• Phu H. Phung, David Sands, and Andrey
Chudnov (2009). Lightweight Self-Protecting
Javascript (ASIACCS 2009)
The papers are available at:
http://www.cse.chalmers.se/~phung/projects/jss

24. Further work
• Case studies for particular web applications
• Fully develop the framework, including
treating mashups, policies that span multiple
pages
• Authoring policies:
– Not easy for the programmer to ensure that all
objects are safe
• Strong motivation for defining a policy language for
authoring policies which are well behaved.

25. Thank you!