Presented by Vaibhav Rastogi

1. Presented by VaibhavRastogi ConScript: Specifying and Enforcing Fine Grained Security Policies fpr JavaScript in the Browser

2. Introduction • 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. ConScript • 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. Looking Ahead • 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. An example • eval considered unsafe • But a necessity for JSON parsing • Approach 1: • Redefine eval • Shallow redefinition • Other access paths to eval may exist

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

7. An example

8. Salient Points • Advice registration • Binding original advised function to new function • Use type safe calls

9. Aspects: Binding Pointcuts to Advice • 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. Deep Advice • Several access paths to designate an object/function • varge = document.getElementById;

11. Deep Advice • 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. Attack Model and Boot Sequence • 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. Advising functions: Implementation • User defined functions • Represented as closures • Point closure to advice function • A bit indicates if advice is enables

14. Advising functions: Implementation • Native functions: • Analogous to user defined functions

15. Advising functions: Implementation • Foreign functions • Like frame[0].postMessage • Use translation table

16. Blessing and Advice Optimizations • Problem of infinite recursion • Solution • Define two functions • bless: enable the advice • curse: disable the advice • Rewrite

17. Blessing and Advice Optimizations • Autobless • Avoid verbosity • More efficient • What if the raw function is not called • Be explicit • curse

18. Advising Script Introduction • Important pointcut • aroundScript

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

20. Securing Advice • Attack 1: toString redefinition • Attack 2: Function.prototype poisoning

21. Securing Advice • Attack 3: Object.prototype poisoning • Attack 4: Malicious getters

22. Securing Advice: Improvements • Eliminate with and eval • Disallow caller access • Introduce a new primitive ucall • Circumvent prototype poisoning • Introduce a poisoning safe primitive hasProp

23. Securing Advice • Secure version of the whitelist policy

24. Policy Validation • 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. Security Labels • Lattice with “is substitutable for” relation • Substitution represented with flow relation

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

27. Policy examples • No dynamic scripts • No string arguments to setInterval, setTimeout

28. Automatic Policy Generation • 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

29. Evaluation: Micro Benchmarks

30. Evaluation: Macro Benchmarks

31. Evaluation: Code Size Increase

32. Impressions • 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. Impressions • 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 VaibhavRastogi Object Views: Fine Grained Sharing in Browsers

35. Key Idea • 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. Threat model • 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

37. View designs: Example

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