Transcript Document

Robust Defenses for
Cross-Site Request
Forgery
Adam Barth, Collin Jackson, John C. Mitchell
Stanford University
15th ACM CCS
1
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
2
Three defending techniques

Validating a secret request token



Validating the HTTP Referer header



Most popular
Fraught with pitfalls
Simplest
Referer header can be suppressed
Validating custom headers attached to
XMLHttpRequests


AJAX interface
Requires sites to valid all state-modifying requests
3
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
4
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
5
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
6
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
7
LOGIN CSRF attack



Search History
Paypal
iGoogle
8
Existing CSRF Defenses

Secret Validation Token


The Referer Header



Session Identifier, Nonce, HMAC of Session
Identifier
Lenient Referer Validation
Strict Referer Validation
Custom HTTP Headers

Attach the custom header XMLHttpRequest
9
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 crossdomain 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
10
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
11
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
12
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
13
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
14
Proposal: Origin header

Security Analysis


Adoption


Rollback and Suppression, DNS Rebinding ,Plugins
Improves and unifies four other proposals and
has been adopted by several working groups
Implementation


Browser side: WebKit, Safari, Firefox
Server side: ModSecurity, Apache
15
Session Initialization

Authenticated as User


Authenticated as Attacker


Predictable session identifier
Login CSRF
Two common approaches to mounting an
attack on session initialization

HTTP Requests and Cookie Overwriting
16
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
17
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
18
Cookie Overwriting



An active network attacker can supply a SetCookie 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
19
Related Work

RequestRodeo



Strips implicit authorization information from
outgoing cross-site HTTP requests
Breaks existing web site functionality
CAPTCHA

Attacker can manually solve CAPTCHAs
20
Conclusions and Advice

Login CSRF


HTTPS


Served over HTTPS
Third-party Content


Strict Referer validation
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
21
My Comments


Will Origin header be widely used
Still exist so many Out-of-Scope threats
22