Science of Web Security and Third-party tracking John Mitchell Dagstuhl October 2012.

Science of Web Security and Third-party tracking

John Mitchell

Dagstuhl October 2012

This talk will cover a few topics

Science of securityWeb modelingExperimental web security studyPrivacy and third-party tracking

Security modeling and analysis

System of interestProperties desired of the system Can include intended purpose or function Or just that failure should not be

catastrophic

Attacker actions and interface to system aka Threat model

Security: the attacker cannot cause the desired properties to fail

System

AttackerAlice

General picture

Users interact with the systemSystem is intended to serve them in some way

If users enter expected input, system will deliver desired output

Attacker may have a different interface and capabilities. Disrupt honest user’s use of the system Learns information intended for others only

Network Attacker

May intercept and alter network traffic; cannot break crypto

Alice

System

Network security

Web Attacker

Sets up malicious site visited by

victim; no control of network

Alice

System

Web security

Measurement?

Threat models can be compared Every mechanism that is secure against a

stronger threat model is secure against a weaker one

Properties can be compared Every mechanism that guarantees a

stronger property also guarantees a weaker one

Experiments?

Some properties amenable to experiment Do users find system convenient? Do known attacks cause harm? Which design process appear to produce

more secure systems?

Some properties inherently analytical Does system resist all attacks against a

certain property, within a given threat model?

Outline


Goals of web security

Safely browse the web Users should be able to visit a variety of

web sites, without incurring harm: No stolen information (without user’s permission) Site A cannot compromise session at Site B

Secure web applications Applications delivered over the web should

have the same security properties we require for stand-alone applications

Other ideas?

A formal model of the web

Includes browser, servers, and networkThreat models include: web attacker with no special network

privilege network attacker that can eavesdrop

and/or modify unencrypted traffic at will

Security goals 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

Alloy [Jackson]

Concepts expressed by relations General logical language

User inputs “scope” to determine precision Tool converts logical expressions to finitary

form by allocating specific number of bits to each possible value

SAT-based analysis Satisfiability checker used to see if formula

is satisfiable Leverage large community working on

efficient SAT checkers

Web modeling examples

abstract sig NetworkEvent extends Event {from: NetworkEndpoint,

to: NetworkEndpoint }abstract sig HTTPEvent extends NetworkEvent {

host: Origin }sig HTTPRequest extends HTTPEvent {

method: Method,path: Path,headers: set HTTPRequestHeader }

sig HTTPResponse extends HTTPEvent {statusCode: Status,headers: set HTTPResponseHeader

}

Principals

A Principal is an entity that controls a set of NetworkEndpoints and owns a set of DNSLabels, which represent fully qualified host names:

abstract sig Principal {servers: set NetworkEndpoint,dnslabels: set DNS

}abstract sig PassivePrincipal

extends Principal{} {servers in HTTPConformist

}

Browsers

A Browser is an HTTPClient together with a set of trusted CertificateAuthorites and a set of ScriptContexts. (For technical convenience, we store the Browser as a property of a ScriptContext.)

abstract sig Browserextends HTTPClient {trustedCA: set CertificateAuthority

}sig ScriptContext {

owner: Origin,location: Browser,transactions: set HTTPTransaction

}

Cookies (modeled as a fact)

Idea: HTTPRequests from Browsers contain only appropriate cookies from previous SetCookieHeaders

fact { all areq:HTTPRequest | {

areq.from in BrowserhasCookie[areq]

} implies all acookie: reqCookies[areq] |some aresp: getBrowserTrans[areq].resp | {aresp.host.dnslabel = areq.host.dnslabelacookie in respCookies[aresp]happensBeforeOrdering[aresp,areq]}

}

Property: session integrity

fun involvedServers[t:HTTPTransaction] : set NetworkEndpoint {

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

+ getTransactionOwner[t].servers }

pred webAttackerInCausalChain[t:HTTPTransaction] { some (WEBATTACKER.servers & involvedServers[t]) }

Alloy metamodel

Sample case studies

HTML5 FormsReferer validationWebAuth protocol

Referer Validation

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

Websites reject a request unless the referer header is from the same

site, or the request is directed at an “entry”

page vetted for CSRF and XSS vulnerabilities

Modeling

Referer header already part of modelAdd check: RefererProtected principals allow HTTP requests with external Referers only on the “LOGIN” page:fact {

all aReq:HTTPRequest | {(getTransaction[aReq].resp.fromin RefererProtected.servers )and isCrossOrigin[aReq]

} implies aReq.path = LOGIN}

Referer header and redirects

referer: http://www.site.com

referer: http://www.site.com

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.

Web extension Origin header records path of

redirects

WebAuth

Web-based Single Sign-On protocolWebAuth and a similar protocol, Central Authentication Service (CAS), are deployed at over 80 universities worldwideAlthough we analyze WebAuth specifically, we have verified the same vulnerability exists in CAS

WebAuth Analysis

Attack 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

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

Challenge

Does CSP prevent XSS?

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

Conclusion of case studies

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 is implemented in Alloy Modeling approach can discover practical new attacks and verify the security of alternate designs, up to a certain size of the model

Outline


Experimental Study

What factors most strongly influence the likely security of a new web site? Developer training? Developer team and commitment?

freelancer vs stock options in startup? Programming language? Library, development framework?

How do we tell? Can we use automated tools to reliably measure

security in order to answer the question above?

Approach

Develop a web application vulnerability metric Combine reports of 4 leading commercial black box

vulnerability scanners and

Evaluate vulnerability metric Using historical benchmarks and our new sample of

applications

Use vulnerability metric to examine the impact of three factors on web application security: developed by startup company or freelancers developer security knowledge Programming language framework

Data Collection and Analysis

Evaluate 27 web applications from 19 Silicon Valley startups and 8

outsourcing freelancers using 5 programming languages.

Correlate vulnerability rate with developed by startup company or

freelancers developer security knowledge (assessed by

a simple quiz programming language used

Comparison of scanner vulnerability detection

Developer security self-assessment

Language usage in sampleN

um

ber

of

ap

plic

ati

on

s

Summary of ResultsSecurity scanners are useful but not perfect

Tuned to current trends in web application development Tool comparisons performed on single testbeds are not predictive in a

statistically meaningful way Combined output of several scanners is a reasonable comparative measure

of code security, compared to other quantitative measures

Based on scanner-based evaluation Freelancers are more prone to introducing injection vulnerabilities than

startup developers, in a statistically meaningful way PHP applications have statistically significant higher rates of injection

vulnerabilities than non-PHP applications; PHP applications tend not to use frameworks

Startup developers are more knowledgeable about cryptographic storage and same-origin policy compared to freelancers, again with statistical significance.

Low correlation between developer security knowledge and the vulnerability rates of their applications

Warning: don’t hire freelancers to build secure web site in PHP.

Outline


Current Page

Browsing History

Financial Information

Health Information

Shopping History

. . .

80+%third-party tracking

should be illegal

Source: Turow et al. 2009

90+%opt outs should be

legally binding

Public opinion on Web tracking

stateful tracking

stateless tracking

tagging

fingerprinting

Tracking technology

HTTP cookiesFlash Local Shared Objects

Silverlight Isolated Storage

content cache

HTTP ETags

window.nameIE userData

HTML5 session/local/global/database storage

TLS session ID & resume

HTTP authentication

browsing history

HTML5 protocol & content handlers

HTTP STS

DNS cacheSource:

[Aggrawal10]

link

this is blue

link

this is purple

User Agent

HTTP ACCEPT Headers

cookies enabled?

screen resolution

browser plug-ins

MIME support

installed fonts

browser add-ons

clock skewSources: [Eckersley10],

[Mayer09]

Anti-tracking efforts

Black lists are difficult to produce and maintain

≈70 companies

opt out

=Do Not Target

Ads

Do Not Track

HTTP header DNT: 1

Advantages universal no updating one click

Adopted by major browsers

10+ million users(≈100x opt-out cookie

users)

Consensus about Do Not Track

Tracking third-party tracking

Stanford DoNotTrack and FourthParty www.donottrack.us cyberlaw.stanford.edu

observe suspicious behaviormonitor ad distributions✓

13email

first name

7email

25+username

(> 100 million users)

Summary


Science of Web Security and Third-party tracking John Mitchell Dagstuhl October 2012.

Documents

Transcript of Science of Web Security and Third-party tracking John Mitchell Dagstuhl October 2012.