1 / 60

Science of Web Security and Third-party tracking

Dagstuhl. October 2012. Science of Web Security and Third-party tracking. John Mitchell. This talk will cover a few topics. Science of security Web modeling Experimental web security study Privacy and third-party tracking. Security modeling and analysis . S ystem of interest

turner
Télécharger la présentation

Science of Web Security and Third-party tracking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

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

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

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

  26. Challenge • Does CSP prevent XSS?

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

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

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

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

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

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

  33. Comparison of scanner vulnerability detection

  34. Developer security self-assessment

  35. Language usage in sample Number of applications

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

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

  38. Current Page

  39. Health Information Financial Information Shopping History . . . Browsing History

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

  41. Tracking technology stateful tracking tagging stateless tracking fingerprinting

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

  43. this is blue link

  44. this is purple link

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

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

  47. ≈70 companies

  48. opt out = Do Not Target Ads

More Related