Improving Web Security:

Size: px

Start display at page:

Download "Improving Web Security:"

Marcus Simon
5 years ago
Views:

1 Finding and fixing vulnerabilities in web security mechanisms Devdatta Akhawe, Adam Barth, Peifung E. Lam, John C. Mitchell and Dawn Song Stanford Computer Security Lab Improving Web Security:

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

3 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

4 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

5 Outline of the talk Attacks and countermeasures for HTML5 Forms Referer validation WebAuth protocol

6 Outline (Cont.) Modeling the Web A formal model of the Web Implementation of the model in Alloy Statistics of Alloy implementation

7 Attacks and countermeasures Attacks and countermeasures HTML5 Forms Referer validation WebAuth protocol

8 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

9 HTML5 Forms (Cont.) HTML5 Forms Spec Same Origin Browser 1. HTML5 Form 2. PUT/DELETE Web Site Cross-Origin 1. HTML5 Form Attacker Site Browser 2. PUT/DELETE X Web Site 2

10 HTML5 Forms - Attack HTML5 Forms Spec Browser 1. HTML5 Form 2. PUT/DELETE X Attacker Site Web Site 2 Attack! Browser 1. HTML5 Form 2. PUT/DELETE 3. HTTP Redirect Attacker Site 4. PUT/DELETE Web Site 2

11 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

12 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

13 Referer Validation - proposal Figure adapted from F. Kerschbaum, Simple cross-site attack prevention, 2007, with attack (in red) added. Web Site 2 X Protected Site Entry Page Allowed link Internal Page X Forbidden and potentially malicious link

14 Referer Validation - Attack Figure adapted from F. Kerschbaum, Simple cross-site attack prevention, 2007, with attack (in red) added. Redirect Attacker Site X Protected Site Entry Page Allowed link Internal Page X Forbidden and potentially malicious link

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

16 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

17 WebAuth Protocol Figure adapted from webauth.stanford.edu/protocol.html UA WAS WebKDC 1. request webkdc-service token 2. return webkdc-service token and session key 3. request resource 4. redirect to WebKDC w/ request token 5. 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

18 WebAuth Protocol - Attack UA WAS WebKDC 1. request webkdc-service token 2. return webkdc-service token and session key 3. request resource 4. redirect to WebKDC w/ request token 5. 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 Attacker completes steps 1-8 and induces the user's browser to send message 9 9. access the URL link w/ id token 10. set cookie w/ app token; return requested resource

19 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

20 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

21 Modeling the Web A formal model of the Web Implementation of the model in Alloy Statistics of Alloy implementation

22 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

23 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

24 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

25 MetaModel in Alloy Event ScriptContext NetworkEvent transactions HTTPTransaction cause cause resp HTTPEvent req RequestAPI HTTPResponse HTTPRequest host statuscode querystring owner FormElement Status attributenamevaluepair body XMLHTTPRequest headers HTTPHeader headers from to cert value name headers RedirectionStatus c401 c200 Token HTTPRequestHeader HTTPResponseHeader path location c303 c304 c305 c306 c307 c301 c302 madeby OriginHeader Secret URL CookieHeader WWWAuthnHeader location SetCookieHeader theorigin host targetorigin thecookie thecookie Certificate DNSRoot Origin Principal UserToken Cookie path targetpath cn parent dnslabel dnslabels domain name value path ne DNS parent ACTIVEATTACKER servers PassivePrincipal UserPassword String1 SecureCookie Path resolvesto NetworkEndpoint WebPrincipal PASSIVEATTACKER SENSITIVE PUBLIC REDIRECT HOME INDEX LOGIN LOGOUT HTTPConformist NormalPrincipal WEBATTACKER PATH TO COMPROMISE HTTPClient HTTPServer SECURE GOOD ORIGINAWARE Browser Firefox InternetExplorer Safari Firefox3 InternetExplorer8 InternetExplorer7

26 Example Alloy code Example code for 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]) }

27 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 Referer Validation , , WebAuth , 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 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.

29 References HTML5 working group, HTML5 Forms, [Online]. Available: IP F. Kerschbaum, Simple cross-site attack prevention, in Proceedings of the Third international workshop on Security and Privacy in Communication networks, R. Schemers and R. Allbery, Webauth v3 technical specification, [Online]. Available: webauth.stanford.edu/protocol.html D. Mazurek, CAS protocol, [Online]. Available:

30 Stanford Computer Security Lab Questions? Thank you!

Robust Defenses for Cross-Site Request Forgery

University of Cyprus Department of Computer Science Advanced Security Topics Robust Defenses for Cross-Site Request Forgery Name: Elena Prodromou Instructor: Dr. Elias Athanasopoulos Authors: Adam Barth,