Cross-Site Request Forgery: Attack and Defense

Tatiana Alexenko Mark Jenne

Suman Deb Roy Wenjun Zeng

Department of Computer Science
University of Missouri Columbia

Department of Computer Science and Software Engineering

Rose-Hulman Institute of Technology


Abstract

Cross Site Request Forgery (CSRF) has emerged as a
potent threat to Web 2.0 applications. Because of the
stateless nature of the HTTP protocol, a malicious
website can force the user's browser to send
unauthorized requests to a trusted site. This demo
provides hands on exposure of the various ways in
which some popular web applications are exploited
using CSRF, in addition to demonstrating techniques
by which CSRF signatures can be detected and
attacks effectively resisted even before initiation. The
user needs only to install a simple extension to get
notified about potential CSRF vulnerabilities.
Because validating the Referer Header is a common
CSRF prevention method, a novel solution to the
Referer Privacy issue will also be demonstrated.


1. Introduction

Cross Site Request Forgery (CSRF) is an attack that
coerces an unaware user to send unauthorized requests
to any web domain by interacting with a seemingly
unrelated entity on a malicious website [1]. Therefore,
CSRF impersonates a legitimate user and exploits the
trust that the website has for him/her. CSRF is listed
among the top 10 web vulnerabilities of 2007 [2].
In this demo, we intend to show how CSRF works
by demonstrating different attack vectors and giving
examples of real CSRF vulnerabilities. This will allow
the audience to become more familiar with the subject,
so they can better understand our defense mechanisms.
After the attack section of the demo, we will quickly
cover the existing defense measures and why they fail
and follow with a demonstration of the new defense
measures we developed.

2. Learn from the attacker
Observe your enemies, for they first find out your
faults.--Antisthenes
It is crucial for the audience to understand how
CSRF looks, works, and propagates. The first part of
our demo will show CSRF from the point of view of
the attacker with real examples.

2.1. Example stock trading website

To better demonstrate the CSRF attacks we created
a stock trading website [3]. The application being
exploited is a simple stock 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 the application, the
attacker needs to create a self-submitting form that
contains the inputs to the real stock trading form has
and submits to the same URL. The server response will
then be loaded inside the invisible iframe, leaving the
user oblivious to the attack.

2.2. The threat is real

The custom demo will be followed by a
demonstration of attacks on live Internet sites including
Dailymotion (www.dailymotion.com/us) and Hi5
(www.hi5.com). We shall create custom playlists in the
users account in Dailymotion, populate it with videos
and then share them to the public profile without the
users knowledge. For Hi5, changing skins and adding
applications to the users profiles can be shown in a
similar way. This section is intended to demonstrate
the ease of penetrating modern web apps that lack
adequate CSRF security measures.

2.3. Propagation

Tricking the victim into visiting the attackers
website is not the only means 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
978-1-4244-5176-0/10/$26.00 2010 IEEE
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE CCNC 2010 proceedings

email message or posted on a social networking
profile. If the target website is vulnerable to Cross-
Site-Scripting (XSS), the attack code can be placed on
the same domain, further confusing the victim of the
attack and bypassing CSRF security measures that rely
on tokens.

3. Defense Mechanisms

The second part of our demonstration will
concentrate on how to prevent CSRF. We will briefly
cover existing defense measures and their drawbacks
and follow with a demonstration of our proposed
solutions.

3.1. Referer Privacy Guard

Checking the Referer header is one such measure.
While it is foolproof when used with HTTP 1.1, many
users do not send Referer headers because of privacy
concerns. The Referer Privacy Guard demo reveals
how a constant flow of random HTTP requests can
mess up the browsing history at the server side, thus
preventing infiltrators from getting access to user
browsing trends. Privacy leak regarding browsing
trends often dissuade service providers from using
referers as a CSRF protection mechanism. We
developed a Mozilla extension that integrates with the
Firefox web-browser to protect the user's browsing
history. The extension generates HTTP requests to
random URLs from the user's browsing history. This
work is also accessible through SourceForge [4]. The
extension allows the user to specify how often the
requests get sent as well as giving users the option of
adding a random URL to the Referrer field of the
extension-generated HTTP request. The latter option is
bound to initiate discussion, because the pairing of the
requested URL and Referer is random which can lead
to combinations that should not exist during normal
browsing. This can affect online advertising and raise
red flags for web administrators [5].

3.2. Detection and Discouragement

Our final section will focus on how to detect CSRF
signatures in web pages and stop it before
commencement. 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).
We implement a client-side defense measure 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
white list. This is necessary because many social
networking applications depend on cross-domain
requests to function. While this method is unlikely to
prevent all CSRF attacks, it will greatly decrease the
number of attacks by making them more difficult to
perform.
The extension needs to be downloaded and
integrated with the browser. On re-running the
browser, CSRF potential applications will be prevented
from loading and a temporary warning message will be
issued to the user for his/her consent in proceeding
with the Request.

4. Benefits

This demo exposes the audience to the pitfalls
related to fancy apps on Web 2.0. It does not dissuade
users from embracing these applications, instead makes
web developers and users aware of the threat and how
to defend against it. The extensions we created can be
easily packaged as a patch and provided to the
customers of a company which wishes to protect its
users from CSRF vulnerabilities.

5. Acknowledgements

This material is based upon work supported by the
National Science Foundation under Grant No.
0649158.
Any opinions, findings, and conclusions or
recommendations expressed in this material are those
of the author(s) and do not necessarily reflect the views
of the National Science Foundation.

6. References

[1]J. Grossman, Cross Site Request Forgery The Sleeping
Giant of Website Vulnerabilities, in RSA Conference, San
Francisco, April 2008.
[2]CSRF Guard. http://www.owasp.org/index.php/ Category:
OWASP_Top_Ten_Project
[3]http://www.csrf.missouri.edu/
[4]http://sourceforge.net/projects/refererprivacyg/
[5]http://www.gadgetopia.com/post/1863, Spamming
Referer Logs
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE CCNC 2010 proceedings