Robust Defenses for Cross-Site Request Forgery

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 2008 • 283945 advertisement impressions from 163767 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 (0.05-0.22%) 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