Advocating Referer Privacy and Detecting Attack Signatures for Cross-Site Request Forgery Prevention

stickyraffleSoftware and s/w Development

Nov 4, 2013 (3 years and 5 months ago)



Advocating Referer Privacy and Detecting
Attack Signatures for Cross
Site Request
Forgery Prevention


Cross Site Request Forgery (CSRF) has emerged as a
potent threat to Web 2.0 applications on the Internet.
Such attacks are caused when a malicious website
forces the user's browser to send unauthorized requests
to a trusted site.
Our work
describes the


of an
Obscuration S
earch method in order to maintain
privacy while using referer headers as the traditional
CSRF protection method. This is followed by injecting
random visited
s in the browsing history to
prevent any breach of privacy. We also propose

a new
solution to test for CSRF vulnerabilities that
intelligently checks

web forms for any relevant CSRF
signatures. The Obscuration Search

method requires
server side changes since it reforms how referers
should be extracted in serv
ers for verification.

form checker

method is completely a client side
browser plugin that can protect users from various
CSRF attack scenarios. Finally, we discovered critical
CSRF vulnerabilities in many popular websites which
have still not been dealt with elegantly. Thi
s paper
aims to delve into CSRF origins from the network
erspective, present a survey of existing
, reframe the referer privacy issue and
safeguard technique

against CSRF.

1. Introduction

The role of Internet has drasticall
y changed over the
last decade. It is now a part of our lives in every

Spearheading this concept is the idea

of Web 2.0

birth of web based communities, hosted, blogs, social
networking, video sharing sites and wikis. Availability
of such a wid
e array of functionalities is commendable.
However, it has left the consumer exposed to serious
security and privacy threats.

Cross Site Request Forgery (CSRF) is an attack that
coerces an unaware user to send unauthorized requests
to any web domain by i
nteracting with a seemingly
unrelated entity on a malicious website. The attack has
been rightly called “the sleeping giant” of all cyber
security threats; considering the fact that most web
developers are either ignorant or overlook its true
potential. T
he general idea behind the vulnerability is
that a web form, hosted by a malicious site, can force
the user’s browser to submit this form to a trusted site
which the user is a member of. Thi
s allows a CSRF
attack to modify the database behind the server at

without the users’ knowledge. The broader picture
being CSRF exploits the strict separation of content
provided by unrelated sites to adversely affect data
confidentiality and integrity.

CSRF is considerably different from its well known

XSS (Cross Site Scripting). In fact, their
attack vectors seem opposite to each other. XSS is the
impersonation of a legitimate website whereas CSRF is
the impersonation of a legitimate user
. Moreover in
XSS, the trust that the user places on a website is
violated. On the other hand, in CSRF, the trust that the
website has on a remote user is breached allowing the
attacker to initiate HTTP requests in context of the
remote user or pretend to
be the remote user entirely.
The attack listed at #5 in OWASP 2007 Top 10 web
application vulnerabilities[]. However, it did not
appear in the same list in 2005.

A number of possible solutions have been suggested
for CSRF mitigation. They however suffer from
various limitations. RequestRodeo [] aims to strip the
implicit authentication tokens from all cross domain
requests. Conversely, it breaks down content sharin

the backbone of social networking today. Use of
a pseudo random value is suggested in []. This methods
are however helpless against login CSRF [].
Authenticating web forms with a secret validation
token seems to be the best embraced CSRF preventi
approach []. However, it is complicated to implement
and could cause leak of this token to other URLs as
pointed out in [] and is the flaw with NoForge[].
Moreover, if the site is vulnerable to XSS, then this
method will not work since XSS holes can be
used to

steal such secret tokens. Considering the fact that 80%
of CSRF vulnerable websites suffer from XSS
vulnerabilities [] as well, the secret token is anything
but a strong protection.

The rest of the paper is organized as follows: In
Section 2 we d
iscuss the framework of the Internet
which has led to CSRF vulnerabilities. Section 3
describes the application we built to test the attacks and
provides description of the key attack vectors. A brief
survey of existing CSRF vulnerabilities on the web is
overed in Section 4. Techniques to maintain referer
privacy when using referers to protect against CSRF
are described in Section 5. In Section 6, we propose a
new method of form checking to test against CSRF
attacks. Finally, Section 6 summarizes the work
highlights avenues for future work.

2. Origins of Cross Site Attacks

CSRF attacks are highly application specific. This
means the effects of its severity span a large spectrum.
Hence, it is not advisable to examine CSRF based on
the application it e
xploits. This section analyses CSRF
from the network level perspective.

2.1. How the Internet works

The Internet functions on several protocols, among
which the Hyper Text Transfer Protocol (HTTP) is of
primary importance. HTTP is used to retrieve
linked resources on the Internet. In other words,
HTTP is the request/response standard of a client and a
server. HTTP defines eight methods in its REQUEST
message, each of which performs specific actions on an
identified resource. Data is such resources m
ay be pre
existing (static) or maybe dynamically generated (SQL
queries). The GET method is used for requesting
representation of a specified resource. The POST
method submits data to be processed using a HTML
form. Form submission typically cause state ch
ange at
the server end.

Moreover, HTTP is a stateless protocol

it does not retain any information about users between
two consecutive requests. More importantly,
does not recognize if a particular request is in itself
state changing until i
t has already been executed

This property has many non
trivial effects.
For example,
the protocol cannot differentiate between
a single HTTP request and cascaded HTTP requests
. It
has also resulted in web developers using session
cookies in ord
er to maintain user state. Cookies
provide implicit authentication. Both these effects are
pivotal reasons for the existence of cross site attacks.

The technology of Web 2.0 demands increased user
interactivity using JavaScript and AJAX. JavaScript is
scripting language that allows programmatic access
to objects within other web applications. AJAX, on the
other hand, allows such web applications to retrieve
data from the server asynchronously in the background
without interfering with refreshing the dis
play of the
entire page. Such access to objects and the consequent
interfered retrieval of data requires efficient access
control mechanisms. The Same Origin Policy was built
for this purpose.

2.2. Same Origin Policy (SOP)

The SOP is an important (and only) security
measure for browsers that allows scripts running on a
page to access methods and properties of sites having
“same origin”. The same origin of two resources is
satisfied if they possess:


The same host name


The s
ame port


The same application layer protocol.

The importance of same origins is undisputed,
especially for web applications which maintain user
state by using HTTP cookies

since servers act on
such cookie information for authentication to perform
ble state changing actions. These rules allow the
browser program to check if there is any attempted
access against SOP when manipulating browser
windows, frames, documents and cookies or dynamic
URL request using XMLHttpRequest. However, the
SOP cannot ch
eck access controls if an unauthorized
HTTP request is sent using a
n indirect

JavaScript can initiate such network communication
through dynamic inclusion of elements in the DOM
tree. This is another important reason for the source of
CSRF attacks.

Scripts can possibly include an HTML element in
the page which can access some network resource like
images, styles, other scripts or iframes. This results in a
cross domain communication as the outgoing
parameters are usually URLs of other websites not

having same origins. The entire picture is that SOP
allows websites to send HTTP requests to any network
address and hence, indirectly allows cross domain


3. CSRF Attack Mechanism

To better demonstrate the CSRF attack vector we

a s
imple stock trading website
( We also made a free hosting
account with x10hosting (
to host the malicious code. The diagram below
illustrates the attack process.

The application being exploited is a simple sto
trading form that asks the user to specify the stock
symbol, number of shares, and action (buy or sell).
When the user submits this form the stock shares are
added (or subtracted) from their account on our site.

To exploit our application, the attacker

needs to create
a self
submitting form that contains the inputs the real
stock trading form has and submits to the same URL:

<form method="post" name=”evil_form”


<input type="hidden" name="stockSymbol"
ue="GOOG" />

<input type="hidden" name="numShares"
value="500" />

<input type="hidden" name="buyOrsell"
value="buy" />





Once the form is submitted, the server will respond by
redirecting the user to the list of stocks they own,
which could alert them because it is not the behavior
they expected from a completely unrelated website.

For this reason the attacker needs to prev
ent the user
from seeing the server response. This can be easily
achieved by replacing the
last three lines of code

to submit the form with an iframe:

<iframe onl
height=”0” width=”0”

The server response will then be loaded
inside of the
invisible iframe, leaving the user oblivious to the

Tricking the victim into visiting the attacker’s website
is not the only way to expose them to the malicious
code. The payload of the attack
can be distributed with
social networking applications and email. A link to the
website can be placed inside an email message or
posted on a social networking profile. If the website
the attacker is using to distribute their code is
vulnerable to XSS, they

can put the attack code right
on their profile or inside of a message.

If the target website is vulnerable to XSS, the attack
code can be placed on the same domain, further
confusing the victim of the attack and allowing to
bypass CSRF security measures
that rely on tokens
(discussed in Section 1).

CSRF can also be used to exploit intranet web
applications and network hardware that uses web
based interfaces. The scariest part

no firewall will
protect these applications as long as the users have

4. A Brief Survey of CSRF Vulnerabilities

In this section we present CSRF vulnerabilities that
exist in popular websites. The presence of threats on
such major web apps clearly indicates that web
developers tend to overlook the risks attached wit
h a
CSRF attack.

4.1. DailyMotion (

An on
demand video publishing and sharing
website strongly interfaced with video blogs. As of
April 2009, the site was getting over 55 million unique
visitors monthly and visitors viewed appr
oximately 17
million pages since January, 2009.”


We discovered CSRF vulnerabilities in a variety of
applications that a user can carry out in DailyMotion.
One such scenario is that an attacker can create a
playlist belonging to the user’s pro
file. He can do so by
creating a simple CSRF redirector [] embedded in an
image source:

<img src =“javascript:void('
ble=no,location=no, menubar=no, scrollbars=no,
status=no, toolbar=no, fullscreen=yes,

Clicking on such an image with this source in a
malicious website would open a blank page giving the
user no idea of what is happening to his DailyMotion
account. This is just the tip of the iceberg. The attacker
can then populate this playlist with any vi
deo of his
choice. Moreover, he can then share the playlist for
public viewing. He can delete videos from existing
playlists or delete the playlist as a whole.

In addition to this, the attacker can update/change
the user’s profile comments at will. This

time we used

an iframe and the link source would look something
like :

<iframe src


write whatever you want”>


These attacks
could considerably violate user
privacy in addition to defamation. Users have their
friends/family in their contacts list, who in turn can be
exposed to unacceptable videos without the user’s

Vulnerability Rating
: High

Last Tested
: July
, 2009.

Browsers employed:

Firefox 3.5, Google Chrome

4.2. ShareBuilder (

ShareBuilder is a member of the Forbes Best
of the Web directory in the investing broker section. It
is one of the most popular dollar
cost average
e with nearly a million accounts”

BOW Directory

Sharebuilder’s Real
Time Stock Trading
application is vulnerable to CSRF. An unsuspecting
Sharebuilder user can be tricked into purchasing or
selling shares of stock chosen by the attacker.
lder does not use form tokens, but requires the
last four digits of the user’s social security number
when money is transferred to their Sharebuilder
account from an outside bank account. However, this
confirmation step is not used if the user already
sited a sufficient amount of money to complete
the malicious transaction into their Sharebuilder

The attack requires two requests to the stock
trading application. The first request must be a request
to sell shares of stock the user does not curre
ntly own
so an error is generated. The second request contains
the inputs necessary for the malicious transaction the
attacker wants to perform.

This vulnerability could allow the attacker to affect
supply and demand of stocks if performed on enough
. It can also be used to harass and inconvenience
the user by interfering with their investing activities
and making them lose money on unprofitable

Vulnerability Rating
: High

Last Tested
: July
, 2009.

Browsers employed:

Firefox 3.5

Hi5 (

“Launched in 2003, hi5 is now one of the world's
largest social networks and a top 20 website globally

with over 60 million monthly unique visitors.”


We found several vulnerable functions on Hi5. Two
them require the attacker to update the code daily
because a random value is sent with every request.
This value, however, is not a one
time token or user
specific, thus giving an attacker a large enough time
frame to perform the attack.

The first vulnera
ble function is the addition of skins
to a target user’s profile. The attacker can perform this
action by embedding the attack payload into a link:



The skinId identifies the skin the attacker wants to
apply to the victim’s profile. “js” is the random token
value that changes daily.

The second vulnerability that uses the “js” value is
found in the status changing application:

POST" name="form0"

<input type="hidden" name="js"

<input type="hidden" name="source"

<input type="hidden" name="topic"

t type="hidden" name="editorId"


<iframe onload="document.forms[0].submit();"

It is also possible to force a user to add an
application to their profile. The code below adds the
iLike application with full access to the user’s


1&"/>add an app</a>

This function does not use the “js” value, giving the
attacker an unlimited time frame to perform the attack.

While the first two vulnerabilities on hi5 can lead to
harassment and defamation, they only affect one user
at a time. The ability to add unwante
d applications
with access to the user’s email can lead to spamming

and other attacks that can affect users who are not even
on hi5.

Vulnerability Rating
: High

Last Tested
: July
, 2009.

Browsers employed:

Firefox 3.5

5. Ensuring Referer Privacy

aders are an integral part of every
REQUEST/RESPONSE. They define various
characteristics of the data that is requested or provided.

header contains the address of the
previous web page from which the current REQUEST
was generated. Validating t

of the
originating REQUEST is traditionally suggested as a
CSRF prevention mechanism. However, this method is
difficult to implement due to the privacy issue
concerning such header information []. This section
describes why referers are a privac
y issue in the first
place followed by a scheme to maintain referer

5.1. The Privacy Issue


field data allows the server to
identify the source of a particular client request. As
each of these requests is received by the server, they

are usually logged in the server logs. This is useful in
some sense, since the server can engender lists of back
links to resources for optimized caching etc. However,
a major side effect is that these back
links expose the
browsing history of the user. N
ote that by browsing
history we mean the order or sequence of websites
visited and not the whole set. Such sensitive
information could be used to violate user privacy and
track them across the web. Moreover, corporate
organizations are concerned with stori
ng such
confidential information that might get disclosed by
the use of referers. However, privacy is not violated by
presence/existence of data (like log files). Privacy is
breached with the flow of information related to such

5.2. The Obscuration

Search Technique

This technique is utilized to extract a specific
resource from many groups of resources without
retrieving any information about the originating group
of that resource. The idea is demonstrated in Fig. 2. A
records company R distributes

one DVD each [D
, D
…. D
] to ‘n’ stores [S
, S
, …… S
]. R has a special
deal with a store S

and D

has a special track not
available to any other DVDs. A collector C wishes to
retrieve D
. However, he has to do so without knowing
which store owns it; otherwise the privacy of the store
with respect to R will break.

C proceeds by choosing ‘n’ different probes [P
… P
]. These probes are concerned only with
collecting D

from S

and handing it over to C, where
i,j=1,2…n. Each probe collects only one D from one
store. Finally, C receives n DVDs, including D

Fig. 2: The Obscuration Search Technique.

This theoretical scenario maintains privacy in the
following manner: C does
not know that S

has a
special deal with R. Any P

has no information about
C’s intention of getting his hands on D
. None of the
stores S

know about the existence of C. Lastly, R does
not realize its DVDs end up with the same person C.
So, in spite of si
gnificant data flow among the levels,
privacy requires restricted information flow.

5.2.1. Obscuration extraction of referers.

Privacy is
determined by uniquely identifiable data relating to an
individual. It depends on how data is stored, accessed
and a
ssociated. Fig. 3 shows the use of obscuration
search method for referer extraction.

In this model, searching all referers based on a
particular user is disallowed since this would
eventually return the whole browsing history of that
user. Instead, the d
atabase can be searched based on a
particular referer. This will return a group of users who
have used visited the site at some point in browsing.
This serves two purposes. Firstly, browsing history
(sequence) of the user is not revealed. Secondly, the
t that a group of users related to a particular web
domain is returned as the result is not a privacy
concern. It is often termed as market analysis and
except a few cases, fairly legal. This method prevents
access to user surfing trends information.


Fig. 3: Obscuration Extraction of Referers

This effectively reduces the referer privacy problem
to that of set relation between the user set and the
referer set. A one
many relation between user
referer is
a privacy issue because it exposes the browsing

of the ‘one’ user. Obscuration extraction changes this
relation to either many
many or many
one. A many
one relation indicates market analysis information.

5.3. Disorder the Browsing History

Utilization of the referrer header field has been
a viable solution to the problem of csrf attacks. The
referrer header allows server
side applications to see
the origin of any state
changing request. The server
can then verify if the referring url is valid and adheres
to the same origin policy.

This method of checking the
referrer header on http requests has not been widely
implemented, though. In response to the
aforementioned privacy concern, many users and
browsers suppress the referrer header field when
sending http requests. Although the
majority of
users do not alter or suppress the referrer
header, a significant enough percentage do to prevent
checking from being implemented as a csrf
protection mechanism on the server

Solving the Privacy Concern

In order to use
the referrer header as a csrf protection
mechanism we sought out a way to ensure referrer
privacy from the client side, which would in turn cause
users to avoid suppression of the header.
Administrators and developers would then be able to
check the refer
rer from the server
side as a csrf
protection method. To solve the privacy concern, we
have developed a mozilla extension that integrates with
the firefox web
browser to protect the user's browsing
history. In order to prevent the browsing patterns and
istory of a user from being maintained in the logs of
intermediary servers, this extension generates http
requests to random urls from the user's current
browsing history and sends them out. These requests
are added to the logs of the servers in question,

effectively breaking the pattern of the user's self
initiated browsing. It is the progression and pattern of
sites visited that raise the privacy concern, not simply a
list of the urls a user has visited. This firefox extension
functions to break that p
attern and secure a user’s
browsing history.

Function of the Extension

When installed in a mozilla firefox browser, this
extension will allow the user to specify a time interval
for random fake requests to be generated and sent out.
The request generat
ion is controlled by a javascript.
The script queries the browsing history and randomly
selects an available url from the history. An http “get”
request is then created and sent to the selected url via
an AJAX call, with response messages that are sent
ack being disregarded. The requests are sent at
randomly selected times from within the preferred time
interval selected by the user. On browser startup the
extension is loaded and continues to operate in the
background for the duration of the user’s bro
sending out the generated fake requests.

6. The Form Checker Method

Automatically detecting CSRF has been dismissed
as nearly impossible because the attack code is
application specific. Many CSRF attacks, however, do
share certain common features.
POST attacks, for
example, will often contain a deep
linked form action
that will not match the domain name of the website the
attack code is located on (unless the attack code is
placed on the target website with XSS). For example,
the real form discusse
d in Section 3 does not have the
full url of the file it submits to:

<form name='tradeForm'


Because the malicious form is located on a different
domain it requires the full url:

<form method="post"


A client
side defense measure can then be
implemented that previews the html code before each
page load and detects potential CSRF attacks. The
detector would first find all form tags and
check the
“action” attribute of the “form” tags for deep linking. If

such forms are found, the CSRF detector will prompt
the user if they want to add the pairing of the URL of
the website the code is located on and the URL of the
form action to a Whitelist
. This is necessary because
many social networking applications depend on Cross
domain requests to function. If the user decides that
website A should not contain forms that submit to
website B, the parser will not load that form or any
other form with tha
t pairing. Because it is possible to
disguise the malicious form by placing it inside of a
link, image or iframe, the intelligent CSRF detector
will also preview pages placed inside these tags. In this
case the detector will find all of the above mentioned

tags and then preview the source of the linked content
in a sandboxed manner (not allowing the content to
load inside of the user’s browser and send the
malicious request). The intelligent parser can check
that images have sources that are indeed images b
looking at the last three characters in the URL (the file
extension). This measure can be bypassed by the
attacker if they change how image files are handled by
the server

for example setting mod_rewrite on
Apache to treat .gif files as .html files.

ce there are few legitimate uses for self
submitting forms, the javascript code performing this
action can also be detected and not allowed to execute
unless the user allows it. The forms found on the
primary page being loaded or the forms inside linked
ntent can also be checked for hidden inputs. While
many legitimate forms have hidden input fields, there
is no practical use for a form that only has hidden
inputs. Such forms can be brought to user’s attention
and not loaded upon the user’s request.

It i
s difficult to think of every possible way the
attacker can hide their malicious code. However, using
the filtering rules mentioned above will make it more
difficult to perform the attack. New filtering rules can
be created for verifying that other content

on the page
is safe to load.

7. Conclusion

<I’l write this later>

8. References

[1] A. Barth, C. Jackson, and J.C. Mitchell, “Robust
Defenses for Cross
Site Request Forgery”,
ACM Conference
on Computer and Communications Security (CCS’08)

[2] W. Zeller and E. W. Felten, “Cross
Site Request
Forgeries: Exploitation and Prevention”,

[3] Z. Mao, N. Li and I. Molloy, “Defeating Cross
Request Forgery Attacks with Browser
Authenticity Protection”, in
Proceedings of the 14

Symposium on Access Control Models and Technologies
(DACMAT ’09),
June 2009.

[4] M. Johns and J. Winter, “RequestRodeo: Client Side
Protection against Session Riding”, in
Proceedings of the
OWASP Europe Conference
, 2006.

[5] J. Burns, “Cross
Site Request Forgery: An Introduction
to common web application weakness”, Information Security
Partners LLC, 2007.

[6] M. Zalewski. “Google Browser Security Hand Book”,

[7] M. Johns, “A First Approach to Counter ‘JavaScript
Malware’”, in
HITBSecConf 2007
, September 2007.

[8] C. Willis, “Preparing for Cross Site Request Forgery
Defense”, in
Black Hat Briefings DC 2008
, February 2008.