1. Presented by Vaibhav Rastogi

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

3.  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

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

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

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

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

9.  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

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

11.  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

12.  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

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

14.  Native functions:  Analogous to user defined functions

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

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

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

18.  Important pointcut  aroundScript

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

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

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

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

23.  Secure version of the whitelist policy

24.  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

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

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

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

28.  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

32.  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

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

34. Presented by Vaibhav Rastogi

35.  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

36.  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

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