ConScript

Report
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

similar documents