science of web security and third-party tracking

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

catastrophicAttacker 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 cryptoAlice

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?

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

Goals of web securitySafely 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 examplesabstract 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

}

PrincipalsA 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

}

BrowsersA 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 integrityfun 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

ModelingReferer 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 redirectsreferer: 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

ChallengeDoes CSP prevent XSS?

Statistics for the case studiesCase Study

Lines of new code

No. of CNF

clausesCNF 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

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

Experimental StudyWhat 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?

ApproachDevelop 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

applicationsUse 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 AnalysisEvaluate 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 sampleNu

mbe

r of a

pplic

atio

ns

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 measuresBased 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.

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

Current Page

Browsing History

Financial InformationHealth 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 handlersHTTP STS

DNS cacheSource:

[Aggrawal10]

link

this is blue

link

this is purple

User Agent

HTTP ACCEPT Headerscookies 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 TrackHTTP 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✓

13emailfirst name

7email

25+username

(> 100 million users)

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