1

Robust Defenses for Cross-Site Request

ForgeryAdam 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 Ident

ifier 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 im

ages, and issuing XMLHttpRequests Same-domain requests to the primary server and cross-do

main requests to the secondary server Log Referer header, User-Agent header, date, client’s clas

s C network, session identifier, document.referer Did not log the client’s IP address, instead logged the HMA

C of client’s IP address

11

Experiment (2/4) Results

Discussion The Referer header is suppressed more often for HTTP req

uests than for HTTPS requests Browsers that suppress the Referer header also suppress t

he document.referrer value But when Referer is suppressed in the network, the docum

ent.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 l

arge-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-i

ns 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 bein

gs 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 st

ores 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 t

o 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 outgo

ing 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 implement

s 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