Presented by Vaibhav Rastogi

 Advent of Web 2.0 and Mashups  Inclusion of untrusted third party content a necessity  Need to restrict the functionality of untrusted content, content that does not need that functionality

 A browser based, security oriented aspect system  Allow hosting page to specify policies  Restrict code execution in the context of the hosting page  Examples  Limiting eval to JSON parsing  Allowing only white-listed strings, scripts

 Security aspects in the browser  Deep aspects with native support  Static and runtime validation strategies for aspects  17 example security and reliability policies for JavaScript  Automatic policy generation  Evaluation

 eval considered unsafe  But a necessity for JSON parsing  Approach 1:  Redefine eval  Shallow redefinition  Other access paths to eval may exist

 Aspects:  Specify code to execute – advice  At particular moments of execution - pointcut  Approach 2  Require browser support  Uses aspects – advice and pointcuts

 Advice registration  Binding original advised function to new function  Use type safe calls

 The around advice  Call the function parameter instead of the function specified as the first parameter  The advice designer decides what to do in the new function  Throw exception  Do some safe execution  Invoke the original function

 Several access paths to designate an object/function var ge = document.getElementById;

 Current state of the art - wrapping of an access path  Shallow advice  Protects only one access path  Conscript’s approach  Deep advice  Registering advice on one access path suffices

 Browser is trusted  Host web site specifies the policies – advice  Advice is trusted – kernel level code  Untrusted scripts (user level code) are loaded after advice specification  Allow libraries to be loaded before advice  They should declare new code only  They should not change the environment in undesirable ways

 User defined functions  Represented as closures  Point closure to advice function  A bit indicates if advice is enables

 Native functions:  Analogous to user defined functions

 Foreign functions  Like frame[0].postMessage  Use translation table

 Problem of infinite recursion  Solution  Define two functions ▪ bless: enable the advice ▪ curse: disable the advice  Rewrite

 Autobless  Avoid verbosity  More efficient  What if the raw function is not called  Be explicit  curse

 Important pointcut  aroundScript

 Advice should not be tampered with  Should be written in a secure manner  A vulnerable advice definition  A whitelist policy for frame messaging

 Attack 1: toString redefinition  Attack 2: Function.prototype poisoning

 Attack 3: Object.prototype poisoning  Attack 4: Malicious getters

 Eliminate with and eval  Disallow caller access  Introduce a new primitive ucall  Circumvent prototype poisoning  Introduce a poisoning safe primitive hasProp

 Secure version of the whitelist policy

 Static validation  ML like type system  Types are annotated with security labels  Two properties  Reference isolation – kernel objects should not flow to user code  Access path integrity of explicitly invoked function

 Lattice with “is substitutable for” relation  Substitution represented with flow relation

 Primitive type: *  Other types similar to ML  Types annotated with security labels  Sample inference rule  Calling trusted foreign functions

 No dynamic scripts  No string arguments to setInterval, setTimeout

 Static: Instrument Script#  Script# converts C# to JS  JS does not have access qualifiers like private  Generate policies enforce private, protected accesses  Runtime  Test in a sandboxed environment what capabilities are used  Strip off all other capabilities

 Neat idea  Impressive performance  No with and eval  Needs browser support  Automatic policy generation  Policies come with host page  Third party developer (attacker) may choose to not use any ConScript supported frameworks

 SetTimeout also unsafe without policy enforcement  Most policies described can be checked statically  Rule set for type inference may not be complete

Presented by Vaibhav Rastogi

 Enable fine grained sharing of JavaScript objects between principals  Let different principals have different views of the objects  Views may be different in  Access rights  Overriding methods to hide some information  Aspects oriented approach

 Two settings  Server side script rewriters  Browsers  View sharer creates object view according to policies  Attacker is the view recipient  Tries to steal information that should not be accessible to it

 Both are very similar aspects oriented approaches  ConScript is for applying JavaScript policies  Object Views is for creating multiple views for sharing