1 Robust Defenses for Cross-Site Request Forgery Adam Barth, Collin Jackson, John C. Mitchell Stanford University 15th ACM CCS

2 Cross-Site Request Forgery Cross-Site Request Forgery (CSRF) attack A malicious site instructs a victim’s browser to send a request to an honest site Leveraging the victim’s network connectivity and browser’s state, such as cookies, to disrupt the integrity of the victim’s session with the honest site

3 Three defending techniques Validating a secret request token Most popular Fraught with pitfalls Validating the HTTP Referer header Simplest Referer header can be suppressed Validating custom headers attached to XMLHttpRequests AJAX interface Requires sites to valid all state-modifying requests

4 Contributions An explanation of the CSRF threat model A study of current browser behavior A proposal for an Origin header containing the information necessary for CSRF defense A study of related session initialization vulnerabilities

5 CSRF Network Connectivity Read Browser State Write Browser State In-Scope Threats Forum Poster Web Attacker Network Attacker Out-of-Scope Threats XSS, Malware, DNS Rebinding, Certificate Errors, Phishing, User Tracking

6 LOGIN CSRF attack (1/2) The attacker forges a login request to an honest site using the attacker’s user name and password at that site

7 LOGIN CSRF attack (2/2) Honest server responds with a Set-Cookie header that instructs the browser to mutate its state by storing a session cookie, logging the user into the honest site as the attacker Session cookie is used to bind subsequent requests to the user’s session and hence to the attacker’s authentication credential

8 LOGIN CSRF attack Search History Paypal iGoogle

9 Existing CSRF Defenses Secret Validation Token Session Identifier, Nonce, HMAC of Session Identifier The Referer Header Lenient Referer Validation Strict Referer Validation Custom HTTP Headers Attach the custom header XMLHttpRequest

10 Experiment (1/4) Design Adverting networks from 5 April 2008 to 8 April advertisement impressions from unique IP address GET and POST requests both over HTTP and HTTPS Requests are generated by submitting forms, requesting images, and issuing XMLHttpRequests Same-domain requests to the primary server and cross- domain requests to the secondary server Log Referer header, User-Agent header, date, client’s class C network, session identifier, document.referer Did not log the client’s IP address, instead logged the HMAC of client’s IP address

11 Experiment (2/4) Results Discussion The Referer header is suppressed more often for HTTP requests than for HTTPS requests Browsers that suppress the Referer header also suppress the document.referrer value But when Referer is suppressed in the network, the document.referrer value is not suppressed

12 Experiment (3/4) The document.referrer value being suppressed PlayStation 3 browser does not support Opera suppresses for cross-site HTTPS request Bug in Firefox 1.0 and 1.5

13 Experiment (4/4) Conclusion CSRF Defense over HTTPS HTTP: percentage (3-11%) of users HTTPS: percentage ( %) of users Site must reject requests that omit the Referer header Privacy Matters Must address privacy concerns in order to effective in large-scale deployments

14 Proposal: Origin header Privacy Includes only the information required to identify the principal that initiated the request Sent only for POST requests Server Behavior All state-modifying requests, including login requests, must be sent using the POST method Server must reject any requests whose Origin header contains an undesired value

15 Proposal: Origin header Security Analysis Rollback and Suppression, DNS Rebinding,Plug- ins Adoption Improves and unifies four other proposals and has been adopted by several working groups Implementation Browser side: WebKit, Safari, Firefox Server side: ModSecurity, Apache

16 Session Initialization Authenticated as User Predictable session identifier Authenticated as Attacker Login CSRF Two common approaches to mounting an attack on session initialization HTTP Requests and Cookie Overwriting

17 HTTP Requests (1/2) OpenID 1. Web attacker visits the Relying Party (Blogger) and beings the authentication process with the Identity Provider (Yahoo!) 2. Identity Provider redirects the attacker’s browser to the “return to” URL of the Relying Party 3. attacker directs the user’s browser to the return to URL 4. The Relying Party completes the OpenID protocol and stores a session cookie in the user’s browser 5. The user is now logged in as the attacker

18 HTTP Requests (2/2) PHP Cookieless Authentication 1. The web attacker logs into the honest web site 2. The web attacker redirects the user’s browser to the URL currently displayed in the attacker’s location bar 3. Because this URL contains the attacker’s session identifier, the user is now logged in as the attacker

19 Cookie Overwriting An active network attacker can supply a Set- Cookie header over a HTTP connection to the same host name as the site and install either a Secure or a non-Secure cookie of the same name Defense cannot be deployed “without breaking standards and existing web apps” Cookie-Integrity header

20 Related Work RequestRodeo Strips implicit authorization information from outgoing cross-site HTTP requests Breaks existing web site functionality CAPTCHA Attacker can manually solve CAPTCHAs

21 Conclusions and Advice Login CSRF Strict Referer validation HTTPS Served over HTTPS Third-party Content Images, hyperlinks should use a framework that implements secret token validation correctly Origin header Eliminating the privacy concerns HTTPS and non-HTTPS requests both work

22 My Comments Will Origin header be widely used Still exist so many Out-of-Scope threats