improving web security - stanford university · 2010-05-03 · d. akhawe, a. barth, p. e. lam, j....

Stan

ford

Com

pute

r Se

curi

ty L

ab

Improving Web Security:Finding and fixing vulnerabilities in web

security mechanisms

Devdatta Akhawe, Adam Barth, Peifung E. Lam, John C. Mitchell and Dawn Song

Monday, May 3, 2010

D. Akhawe, A. Barth, P. E. Lam, J. C. Mitchell and D. Song Improving Web Security

Introduction

• The Web is complex and fast evolving.

• New browser features, protocols, and standards added at a rapid pace.

• Vulnerabilities and security invariants assumed by web applications.

• We believe that abstract yet informed models of the Web will be amenable to automation, reveal practical attacks, and support useful evaluation of alternate designs.

Monday, May 3, 2010


Introduction (cont.)

• The Web mechanisms we have studied include:

• HTML5 Forms

• Referer validation

• WebAuth protocol

• Our analysis reveals previously unknown attacks

• Countermeasures proposed for each attack

Monday, May 3, 2010


Introduction (cont.)

• These web mechanisms were analyzed using a common approach we have developed which involves:

• A formal model of the web

• Implementation of the formal model in Alloy

• Modeling of the web mechanisms under study in Alloy

Monday, May 3, 2010


Outline of the talk

• Attacks and countermeasures for

• HTML5 Forms



Monday, May 3, 2010


Outline (Cont.)

Modeling the Web

• A formal model of the Web

• Implementation of the model in Alloy

• Statistics of Alloy implementation

Monday, May 3, 2010


Attacks and countermeasures

• Attacks and countermeasures

• HTML5 Forms



Monday, May 3, 2010


HTML5 Forms

• HTML5 is the next major revision of HTML

• FormElement API in HTML5 can generate HTTP requests with PUT and DELETE methods

• Same origin policy applies to such requests

Monday, May 3, 2010


HTML5 Forms (Cont.)

Browser

HTML5 Forms Spec

Browser

Attacker Site

Web Site 2

2. PUT/DELETEX

Cross-Origin

Same Origin

Web Site

1. HTML5 Form

1. HTML5 Form

2. PUT/DELETE

Monday, May 3, 2010


HTML5 Forms - Attack

Browser

Attacker Site

Web Site 2

2. PUT/DELETEX

Browser

Attacker Site

Web Site 24. PUT/DELETE

1. HTML5 Form

3. HTTP Redirect

2. PUT/DELETE

1. HTML5 Form

HTML5 Forms Spec

Attack!

Monday, May 3, 2010


HTML5 Forms - Exploitation and Countermeasure

Exploitation

• Attacker could illegitimately modify/delete resources on a RESTful website

Countermeasure

• Refuse to follow redirects of PUT/DELETE requests generated from HTML Forms

• Verified the fix up to a finite size in our model

• Recommendation accepted by the HTML5 working group

Monday, May 3, 2010


Referer Validation

• A proposed defense against Cross-Site Request Forgery (CSRF) and Cross-Site Scripting (XSS) [F. Kerschbaum, 2007]

• Websites would reject a request unless 1. the referer header is from the same site, or 2. the request is directed at an “entry” page vetted for CSRF and XSS vulnerabilities

Monday, May 3, 2010


Referer Validation - proposalFigure adapted from F. Kerschbaum, “Simple cross-site attack prevention,” 2007, with attack (in red) added.

Web Site 2 Protected Site

Entry Page

Internal Page

X

X

Allowed link

Forbidden and potentially

malicious link

Monday, May 3, 2010


Referer Validation - AttackFigure adapted from F. Kerschbaum, “Simple cross-site attack prevention,” 2007, with attack (in red) added.

Attacker Site Protected Site

Entry Page

Internal Page

X

X

Allowed link

Forbidden and potentially

malicious link

Redirect

Monday, May 3, 2010


Referer Validation - Countermeasure

Exploitation

• CSRF and XSS can be carried out on websites protected with Referer Validation

Countermeasure

• This vulnerability is difficult to correct as Referer header has been widely deployed

• Websites can try to suppress all outgoing Referer headers using, for example, the noreferrer relation attribute on hyperlinks.

Monday, May 3, 2010


WebAuth

• Web-based Single Sign-On protocol

• WebAuth and a similar protocol, Central Authentication Service (CAS), are deployed at over 80 universities worldwide

• Although we analyze WebAuth specifically, we have verified the same vulnerability exists in CAS

Monday, May 3, 2010


WebAuth Protocol Figure adapted from http://webauth.stanford.edu/protocol.html

1. request webkdc-service token

WebKDC

2. return webkdc-service token and session key

UA WAS

3. request resource

4. redirect to WebKDC w/ request token


6. return login form w/ request token in a hidden form field

7. post login form w/ user credentials

8. set cookie w/ webkdc-proxy token; return a URL w/ id token pointing to WAS

9. access the URL link w/ id token

10. set cookie w/ app token; return requested resource

Monday, May 3, 2010

http://webauth.stanford.edu/protocol.html





WebAuth Protocol - Attack

1. request webkdc-service token

WebKDC

2. return webkdc-service token and session key

UA WAS

3. request resource



6. return login form w/ request token in a hidden form field

7. post login form w/ user credentials

8. set cookie w/ webkdc-proxy token; return a URL w/ id token pointing to WAS

9. access the URL link w/ id token

10. set cookie w/ app token; return requested resource

Attacker completes steps 1-8 and induces the user's browser to

send message 9

Monday, May 3, 2010


WebAuth - exploitation

Exploitations

• An insider can share privileged web resources with unprivileged users without sharing login credentials

• Attacker can steal sensitive user information by logging users into attacker’s account

Monday, May 3, 2010


WebAuth - countermeasure

Countermeasure

• Store a nonce in a host cookie to bind messages 3 and 9, and splice in messages in between by including the nonce in the request and id tokens.

• Verified the fix up to a finite size in our model

Monday, May 3, 2010


Modeling the Web

• A formal model of the Web

• Implementation of the model in Alloy

• Statistics of Alloy implementation

Monday, May 3, 2010


A formal model of the web

• We model web entities including browser, servers, and network

• Our threat models include attackers with various capabilities, such as:

• web attacker with no special network privilege, and

• network attacker that can eavesdrop and/or modify unencrypted traffic at will

Monday, May 3, 2010


A formal model of the web (cont.)

Main security goals we have identified include:

• Security invariants

• Assumptions about how today’s Web works

• Example: no DELETE in cross-origin HTTP requests

• Session integrity

• Attacker does not participate in the HTTP transaction

Monday, May 3, 2010


Alloy

• A declarative language based on first-order logic

• Facts and predicates about a model are declared

• The Alloy code is translated into a SAT instance

• SAT solver searches for counterexamples using bounded exhaustive search

Monday, May 3, 2010


MetaModel in Alloy

servers

thecookie

host

host

parent

madeBy

cn

cert

path

dnslabel

namevalue

statusCode

cause

transactions

location

headers

domain path

reqresp

queryString

targetPath

targetOrigin thecookie

owner

dnslabels name value

headers

parent

from to

path

cause

body

theorigin

ne

resolvesTo

headers

OriginDNSRoot

XMLHTTPRequest

HTTPEvent

WWWAuthnHeader

HTTPResponse

HTTPClient

PUBLIC

Principal

Secret

UserToken

HTTPHeader

HTTPResponseHeaderc200RedirectionStatus

Status

UserPasswordACTIVEATTACKER

HTTPTransaction

Browser

Firefox

SENSITIVE

SetCookieHeader

NormalPrincipal

GOOD

Path

HOME

Firefox3

FormElement

PassivePrincipal

WebPrincipal

HTTPRequest

Certificate

INDEX

Token

PATH TO COMPROMISE

LOGIN

ScriptContext

attributeNameValuePair

String1

InternetExplorer7

WEBATTACKER

SecureCookie

SECURE

Safari

REDIRECT

Event

RequestAPI

LOGOUTPASSIVEATTACKER

ORIGINAWARE

NetworkEvent

InternetExplorer

location

InternetExplorer8

OriginHeader

HTTPRequestHeader

CookieHeader

HTTPServer

DNS

Cookie

HTTPConformist

NetworkEndpoint

c302c301 URL

c401

c307c306c305c304c303

Monday, May 3, 2010


Example Alloy code

• Example code for session integrityfun involvedServers[t:HTTPTransaction]:set NetworkEndpoint{

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

+ getTransactionOwner[t].servers

}

pred webAttackerInCausalChain[t:HTTPTransaction]{

some (WEBATTACKER.servers & involvedServers[t])

}

Monday, May 3, 2010


Statistics for the case studies

Case Study Lines of new code

No. of CNF clauses

CNF gen. time (sec)

CNF solve time (sec)

HTML5 Form 20 976,174 27.67 73.54

Referer Validation

35 974,924 30.75 9.06

WebAuth 214 355,093 602.4 35.44

• The base model contains some 2,000 lines of code• Tests were performed on an Intel Core 2 Duo 3.16GHz

CPU with 3.2 GB memory

Monday, May 3, 2010


Conclusion

• We identified previously unknown attacks in HTML5 Forms, Referer validation, and WebAuth

• Proposed countermeasures to the attacks.

• These attacks are identified based on a formal model the Web that we have developed, which is then implemented in the Alloy language.

• This modeling approach not only enables us to discover practical new attacks, but also serves to verify the security of alternate designs, up to a certain size of the model.

Monday, May 3, 2010


References

✤ HTML5 working group, “HTML5 Forms,” 2010. [Online]. Available: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html

✤ IP F. Kerschbaum, “Simple cross-site attack prevention,” in Proceedings of the Third international workshop on Security and Privacy in Communication networks, 2007.

✤ R. Schemers and R. Allbery, “Webauth v3 technical specification,” 2009. [Online]. Available: http://webauth.stanford.edu/protocol.html

✤ D. Mazurek, “CAS protocol,” 2005. [Online]. Available: http://www.jasig.org/cas/protocol

Monday, May 3, 2010

http://webauth

http://webauth

http://webauth

http://webauth

http://www.jasig.org/cas/protocol

http://www.jasig.org/cas/protocol

Stan

ford

Com

pute

r Se

curi

ty L

ab

Questions ?

Thank you!

Monday, May 3, 2010

improving web security - stanford university · 2010-05-03 · d. akhawe, a. barth, p. e. lam, j....

Documents