Exploring Web Security & Privacy: Science of Security and Third-Party Tracking

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

2. This talk will cover a few topics • Science of security • Web modeling • Experimental web security study • Privacy and third-party tracking

3. Security modeling and analysis • Systemof interest • Properties 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

4. General picture • Users interact with the system • System 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 System Alice Attacker

5. Network security Network Attacker May intercept and alter network traffic; cannot break crypto System Alice

6. Web security System Web Attacker Sets up malicious site visited by victim; no control of network Alice

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

8. 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 againsta certain property, within a given threat model?

9. Outline • Science of security • Web modeling • Experimental web security study • Privacy and third-party tracking

10. 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?

11. A formal model of the web • Includes browser, servers, and network • Threat 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

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

13. 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 }

14. 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 }

15. 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 Browser extends HTTPClient { trustedCA: set CertificateAuthority } sig ScriptContext { owner: Origin, location: Browser, transactions: set HTTPTransaction }

16. Cookies (modeled as a fact) • Idea: HTTPRequestsfrom Browsers contain only appropriate cookies from previous SetCookieHeaders fact { all areq:HTTPRequest | { areq.fromin Browser hasCookie[areq] } implies all acookie: reqCookies[areq] | some aresp: getBrowserTrans[areq].resp | { aresp.host.dnslabel= areq.host.dnslabel acookiein respCookies[aresp] happensBeforeOrdering[aresp,areq] } }

17. Property: session integrity fun involvedServers[t:HTTPTransaction] : set NetworkEndpoint { (t.*cause & HTTPTransaction).resp.from + getTransactionOwner[t].servers } predwebAttackerInCausalChain[t:HTTPTransaction] { some (WEBATTACKER.servers & involvedServers[t]) }

18. Alloy metamodel

19. Sample case studies • HTML5 Forms • Referer validation • WebAuth protocol

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

21. Modeling • Referer header already part of model • Add check: RefererProtected principals allowHTTP requests with external Referers only on the “LOGIN” page: fact { all aReq:HTTPRequest | { (getTransaction[aReq].resp.from in RefererProtected.servers ) and isCrossOrigin[aReq] } implies aReq.path = LOGIN }

22. Referer header and redirects referer: http://www.site.com referer: http://www.site.com

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

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

26. WebAuthAnalysis • 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

27. Challenge • Does CSP prevent XSS?

28. Statistics for the case studies • 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

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

30. Outline • Science of security • Web modeling • Experimental web security study • Privacy and third-party tracking

31. 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?

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

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

34. Comparison of scanner vulnerability detection

35. Developer security self-assessment

36. Language usage in sample Number of applications

37. Summary of Results • Security 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.

38. Outline • Science of security • Web modeling • Experimental web security study • Privacy and third-party tracking

40. Current Page

41. Health Information Financial Information Shopping History . . . Browsing History

42. Public opinion on Web tracking 80+% 90+% third-party tracking should be illegal opt outs should be legally binding Source: Turow et al. 2009

43. Tracking technology stateful tracking tagging stateless tracking fingerprinting

44. HTTP cookies Flash Local Shared Objects HTTP authentication Silverlight Isolated Storage HTTP ETags TLS session ID & resume content cache browsing history IE userData window.name HTML5 protocol & content handlers HTTP STS HTML5 session/local/global/database storage DNS cache Source: [Aggrawal10]

45. this is blue link

46. this is purple link

47. User Agent installed fonts HTTP ACCEPT Headers cookies enabled? browser plug-ins browser add-ons MIME support screen resolution clock skew Sources: [Eckersley10], [Mayer09]

48. Anti-tracking efforts Black lists are difficult to produce and maintain

49. ≈70 companies

50. opt out = Do Not Target Ads