Towards a Formal Foundation of Web Security

hotbroodSecurity

Nov 3, 2013 (4 years and 1 month ago)

68 views

Towards a Formal Foundation of
Web Security

devdatta

akhawe

/
adam

barth

/
peifung

eric

lam

john
mitchell

/ dawn song

motivation

the web is interesting

web security is hard

formalization will help

informed abstract
models

of the web platform

will be amenable to
automation,


reveal
practical

attacks


and support useful evaluation of
alternate

designs.

web security 101

abstract model

alloy implementation

case studies



The complete isolation that
SOP
provides is
too coarse
for modern applications.

browsers handle code + documents from multiple sources
and need to ensure integrity and confidentiality

The security of the whole system is a global property
based on invariants at all three components

Network

robber.com

bank.com

Web Browser

robber.com

bank.com

Same Origin Policy


code
from different websites or
“origins” shouldn’t interfere

User

Same Origin Event


Cross Origin Event

web security 101

abstract model

alloy implementation

case studies



User

The security of the whole system is a global property
based on invariants at all three components

Network

robber.com

bank.com

Web Browser

robber.com

bank.com

User

Simple model of user


not
confused and
follows security
indicators

Web Browser

Network

Web
Browser

Network

network

browser

threats

goals

network

browser

threats

goals


The sandbox in which code runs


what are the semantics of the
isolation? Origin, path, http(s)?

Script
Context


Location bar, http(s), lock icon


who decides what is shown ?

User
Interface


Stored passwords/cookies


when to send them?

State
Storage

network

browser

threats

goals

network

browser

threats

goals


Connected to network


May break specification (esp. attacker)


Many to many relationship with DNS

servers


HTTP Methods, status codes, headers


Integrity


some headers/methods
determined by attacker

http


Different APIs with specific constraints


For example, XHR works only same
-
origin, Forms only allow GET/POST

network
requests

network

browser

threats

goals

network

browser

threats

goals

web attacker


robber.com


browser APIs only

gadget attacker


can inject limited form of content


comments on a blog

network attacker


can modify network traffic


except encrypted content


Malicious person with his own site


No special network privileges


Key threat model

threat model hierarchy

Note that any protocol not over
HTTPS can be easily subverted by
the network attacker

network

browser

threats

goals

network

browser

threats

goals


Session integrity


Any action that an honest server takes should not be
directly/indirectly caused by a dishonest/
untrusted

principal


A request caused by robber.com shouldn’t reduce
money in my bank account



Don’t break web invariants


Do not increase attack surface of benign applications


For example, currently cross
-
origin DELETE/PUT
requests with ambient authorization (cookies) aren’t
allowed

security goals


Session integrity


Any action that an honest server takes should not be
directly/indirectly caused by a dishonest/
untrusted

principal


A request caused by robber.com shouldn’t reduce
money in my bank account

web security 101

abstract model

alloy implementation

case studies



Alloy


An object modeling language


Executable model eased development


Bounded model checker


Translates predicates to SAT instances


Easy visualization of counterexamples

metamodel


session integrity

// a function that for a given transaction

// tells the list of servers involved in causing it


fun
involvedServers
[t:HTTPTransaction]:set
NetworkEndpoint
{


// the
ScriptContext

origin


getTransactionOwner
[t].servers


// get list of servers involved in redirect chain


+ (t.*cause &
HTTPTransaction
).
resp.from

}



pred

webAttackerInCausalChain
[t:HTTPTransaction]{


// see if
WebAttacker

controlled server in set of involved


some (
WEBATTACKER.servers

&
involvedServers
[t])

}




web security 101

abstract model

alloy implementation

case studies



Name

Type of vulnerability

Previously

Origin Header

integrity violation

known

Cross

Origin Resource
Sharing

breaks invariant

known

HTML5 Form

breaks invariant

unknown

Referer

Validation

integrity violation

unknown

WebAuth

session

fixation

unknown

Name

Type of vulnerability

Previously

Origin Header

integrity violation

known

Cross

Origin Resource
Sharing

breaks invariant

known

HTML5 Form

breaks invariant

unknown

Referer

Validation

integrity violation

unknown

WebAuth

session

fixation

unknown

case studies

case studies


HTML5 Form vulnerability


Extremely simple vulnerability


Missed completely by many experts until our
study


Referer

Validation Vulnerability


Past verification not detailed enough


WebAuth

Vulnerability


More complicated


Hard to find without such analysis

HTML5 Form

HTML5

GET/POST

DELETE

PUT

GET/POST

DELETE

PUT

robber.com

bank.com

GET/POST

GET/POST


HTML4

Page at robber.com

the attack

HTML5

PUT

PUT ???

cross origin redirect
to bank.com

“Don’t break web invariants” violated

robber.com

bank.com

Page at robber.com

Fix is to disable cross
-
origin redirects
for special methods
; model doesn’t
find any error after fix

alloy counterexample

(actual snapshot)

Referer

Validation

WebAuth

WebAuth


Single sign on solution at Stanford


called
CalNet

at Berkeley


also common in other academic institutions


Single sign on: one password to rule them all


Provides a service similar to Kerberos, but on web


At least two parties other than user


The single sign on provider (
WebAuth

Server)


The application, e.g. library services

Application

WebAuth

Server

GET Secret

Access Denied! Login at
WebAuth

(redirect)

login form

Username

Password

Send Secret and Set
Cookie identifying
user for future

Username/Password ok!
Redirect to App with
identifier key

Run Crypto Checks on
Identifier sent

Identifier Key

This completes the login
procedure

the attack

Application

WebAuth

Server

GET secret

Access Denied! Login
at
WebAuth

(redirect)

Username

Password

Username /Password ok!
Redirect to App with
identifier key

Run Crypto Checks on
Identifier sent

BLOCK and
save link

Set cookie
identifying user as
ATTACKER

Send the link

Follow link

attacker

benign user

login form

Attacker’s credentials

that identifies attacker

Is this really that bad ?

why this is bad


At UC Berkeley, I pay my bills via a service that
uses
CalNet


Could be fooled into paying someone else’s
bill


Fix is to add a nonce to ensure that the
application remembers context


model fails
to find attack after fix

conclusion

informed abstract
models

of the web platform

will be amenable to
automation,

reveal
practical attacks

and support useful evaluation of
alternate designs.

informed abstract
models

of the web platform

will be amenable to
automation,


reveal
practical

attacks


and support useful evaluation of
alternate

designs.

images from sxc.hu


http://bit.ly/csf10
-
websec

thank you