HEURISTICS FOR PREVENTING CROSS SITE REQUEST FORGERY ATTACKS Thesis Submitted in partial fulfillment of the requirements for the degree of MASTER OF TECHNOLOGY in COMPUTER SCIENCE & ENGINEERING - INFORMATION SECURITY by RAMARAO RAMISETTY (07IS07F) DEPARTMENT OF COMPUTER ENGINEERING NATIONAL INSTITUTE OF TECHNOLOGY KARNATAKA SURATHKAL, MANGALORE-575025 JULY, 2009
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
HEURISTICS FOR PREVENTING
CROSS SITE REQUEST FORGERY
ATTACKS
Thesis
Submitted in partial fulfillment of the requirements for the degree of
MASTER OF TECHNOLOGY in
COMPUTER SCIENCE & ENGINEERING - INFORMATION
SECURITY
by
RAMARAO RAMISETTY
(07IS07F)
DEPARTMENT OF COMPUTER ENGINEERING
NATIONAL INSTITUTE OF TECHNOLOGY KARNATAKA
SURATHKAL, MANGALORE-575025
JULY, 2009
Dedicated
To
My Parents
&
My Family Members
D E C L A R A T I O N
I hereby declare that the Report of the P.G Project Work entitled "HEURISTICS
FOR PREVENTING CROSS SITE REQUEST FORGERY ATTACKS " which
is being submitted to the National Institute of Technology Karnataka, Surathkal,
in partial fulfillment of the requirements for the award of the Degree of Master of
Technology in Computer Science & Engineering - Information Security in the
Department of Computer Engineering, is a bonafide report of the work carried out by
me. The material contained in this report has not been submitted to any University or
Institution for the award of any degree.
07IS07F, RAMARAO.R
(Register Number, Name & Signature of the Student)
Department of Computer Engineering.
Place: NITK, SURATHKAL
Date: ............................
C E R T I F I C A T E
This is to certify that the P.G Project Work Report entitled "HEURISTICS FOR
PREVENTING CROSS SITE REQUEST FORGERY ATTACKS" submitted by
Ramarao Ramisetty, (Register Number: 07IS07F) as the record of the work carried
out by him, is accepted as the P.G. Project Work Report submission in partial
fulfillment of the requirements for the award of the Degree of Master of Technology
in Computer Science & Engineering - Information Security in the Department of
Computer Engineering.
…………………………. ……………………….
External Guide Internal Guide
(Name and Signature (Name and Signature
with date and seal) with date and seal)
……………………………..
Chairman – DPGC
(Signature with Date and Seal)
i
ACKNOWLEDGMENTS
I take this opportunity to express my deepest gratitude and appreciation to all those
people who made this project work easier with words of encouragement, motivation,
discipline, and faith by offering different places to look forward to expanding my
ideas and helped me towards the successful completion of this project work.
First, I would like to express my sincere gratitude to my guide Radhesh Mohandas,
adjunct faculty, Department of Computer Engineering, NITK, Surathkal and project
coordinator & guide Mr. Alwyn Roshan Pais, Sr. Lecturer, Department of Computer
Engineering, National Institute of Technology Karnataka, Surathkal for their
motivating suggestions, insightful advice, invaluable guidance, help and support in
successful completion of this project and also for constant encouragement and advice
throughout my M.Tech programme.
I would like to take this opportunity to express my thanks to the teaching and
nonteaching staff of Department of Computer Engineering, NITK for their
invaluable help and support in these two years of my study. I would also like to thank
Department of Computer Engineering, NITK Surathkal for providing all facilities
to complete this research work. I would like to thank the Department of Information
Technology, Govt. of INDIA for offering Information Security as M.Tech
specialization under ISEA project. I am also grateful to Rod team members and all
my classmates for their help, encouragement and invaluable suggestions.
Finally, I would like to thank all those whose direct and indirect support helped me in
completing my project work & thesis in time.
Ramarao.R
(07IS07F).
ii
ABSTRACT
Cross Site Request Forgery (CSRF) is an attack on web applications which exploits
the trust of authenticated users. This attack allows the attacker to make arbitrary
HTTP requests on behalf of victim user who is currently logged in to the site.
Currently very few defensive mechanisms like Secret validation token, the referer
header, custom HTTP header and Origin header are available to prevent this attack
and none of these mechanisms are providing complete protection to the web
applications from CSRF attacks. This project aims at providing heuristics for
preventing Cross Site Request Forgery attacks.
In this project, we proposed the following solutions: 1) A client-side proxy solution
that detects and prevents CSRF attacks using IMG elements or other HTML elements
which are used to access the images with static URLs for the web page. 2) A semi-
automated mechanism for the SERIDE code to prevent the CSRF attacks in PHP
based web applications.
Keywords: Cross Site Request Forgery, Client-side proxy solution, SERIDE, Image
based CSRF, SA-SERIDE tool.
iii
CONTENTS
Acknowledgements………………………………………………………................... i
Abstract…………………………………………………………………..................... ii
Contents………………………………………………………………….................... iii
List of Figures and Tables…….……………………………………….........................vi
Nomenclature………………………..………………………………………..…….. viii
CHAPTER 1 INTRODUCTION ............................................................................ 1
1.1 Motivation ..................................................................................................... 2
1.2 Implicit authentication ................................................................................... 3
1.3 Types of CSRF attacks ................................................................................... 7
1.4 Working procedure of CSRF attack ................................................................ 8
1.5 Common ways to perform CSRF attacks ........................................................ 9
1.6 Example CSRF attacks ................................................................................. 11
1.7 Real-world CSRF attacks ............................................................................. 18
1.8 Login CSRF ................................................................................................. 19
1.9 CSRF Vs XSS .............................................................................................. 21
1.10 Organization of the Thesis.......................................................................... 22
CHAPTER 2 EXISTING CSRF DEFENSES ....................................................... 23
2.1 Existing CSRF defensive mechanisms.......................................................... 23
2.1.1 Secret Validation Token ........................................................................ 23
2.1.2 The Referer Header ............................................................................... 26
2.1.3 Custom HTTP Headers ......................................................................... 29
2.1.4 Origin Header ....................................................................................... 29
2.1.5 CAPTCHAs .......................................................................................... 30
2.2 Prevention measures that do NOT work ...................................................... 31
2.2.1 Secret cookie ........................................................................................ 31
2.2.2 Accepting only HTTP POST requests......................................................31
2.2.3 URL rewriting...........................................................................................32
2.3 Partial solutions to limit the risks of CSRF attacks ...................................... 32
2.4 Existing tools for preventing CSRF attacks.....................................................34
iv
2.4.1 RequestRodeo: Client side protection against CSRF attacks .................. 34
2.4.2 NoForge ............................................................................................... 39
CHAPTER 3 PROBLEM STATEMENT ............................................................. 45
CHAPTER 4 PREVENTING IMAGE BASED CSRF ATTACKS………..........46
4.1 Image Retrieval ............................................................................................ 46
4.2 Image based CSRF attacks ........................................................................... 51
4.3 Prevention of Image based CSRF attacks ..................................................... 54
4.3.1 A Proxy-Based Solution........................................................................ 55
4.3.2 Limitations ........................................................................................... 55
4.4 Implementation Details ................................................................................ 56
4.5 Experimental Results ................................................................................... 58
4.6 Future Work ................................................................................................. 59
CHAPTER 5 SA-SERIDE: SEMI-AUTOMATED SERIDE TOOL...................60
5.1 SERIDE: SEssion RIding DEfender ............................................................. 60
5.1.1 SERIDE working procedure .................................................................. 61
5.1.2 Implementation details of SERIDE ....................................................... 62
5.1.3 Installation and usage of SERIDE ......................................................... 66
5.2 Required changes to improve the SERIDE code..............................................67
5.2.1 Randomized selection of hashing algorithms (MD5, SHA1) for
generating a token ................................................................................. 67
5.2.2 Improvement to the seride_link() function ........................................... 68
5.2.3 Improvements to the SERIDE (seride_v0.2) code ................................. 69
5.3 Semi-Automated SERIDE (SA-SERIDE) Tool ........................................... 69
5.3.1 SA-SERIDE working procedure ........................................................... 70
5.3.2 Implementation details of SA-SERIDE Tool ......................................... 71
5.3.3 Installation of SA-SERIDE Tool ........................................................... 73
5.3.4 Experimental results ............................................................................. 73
5.3.4.1 Sample application ........................................................................... 73
5.3.4.2 Sample screenshots of SA-SERIDE Tool .......................................... 77
5.3.4 Future work .......................................................................................... 80
CHAPTER 6 CONCLUSION AND SCOPE FOR FUTURE WORK ................ 82
6.1 Conclusion ................................................................................................... 82
v
6.2 Scope for Future Work ................................................................................. 82
BIBLIOGRAPHY .................................................................................................. 84
APPENDIXES ....................................................................................................... 87
OWASP THE TEN MOST CRITICAL WEB APPLICATION SECURITY
VULNERABILITIES ........................................................................................ 87
CSRFTester Tool ............................................................................................... 89
vi
List of Figures and Tables
Figure 1.1 Using cookies for client-side state….……………………………………4
Figure 1.2 Using sessions for server-side state…………………………….............. 5
Figure 1.3 The Web Browser has established an authenticated session…………….8
Figure 1.4 A valid request…………………………………………………………...8
Figure 1.5 A CSRF attack………………………………………………………….. 9
Figure 1.6 Legitimate money transaction form………………………….….............17
Figure 1.7 Malicious CSRF page for POST parameters……………….……………18
Figure 1.8 Event trace diagram for a login CSRF attack…………………………... 20
Figure 2.1 Intercepting implicit HTTP authentication……………………………... 37
Figure 2.2 Placement of the CSRF proxy…………..……………………………… 39
Figure 2.3 Request processing……………………………………………………... 40
Figure 2.4 Reply processing………………………………………………................43
Figure 4.1 CSRF attack using IMG element…………………………………...........52
Figure 4.2 Client-Side Proxy Solution………………………………………………55
Figure 4.3 CSRFTester tool……………...………………………………………….56
Figure 4.4 Test results on cmt.nitk.ac.in chat forum…...……………………………59
Figure 5.1 SERIDE token generation and validation for a form...…………………..61
Figure 5.2 SERIDE token generation and validation for a link…………………….. 62
Figure 5.3 SA-SERIDE tool for both form and link validation and token
Handling………………………………………………............................70
Figure 5.4 buyshares.php form………………………………………………………74
Figure 5.5 buyresult.php output……………………………………………………...74
Figure 5.6 CSRF attack using buymalicious.php file………………………………..75
Figure 5.7 buyshares.php form (with SERIDE)……………………………………..76
Figure 5.8 buyresult.php output (with SERIDE)…………………………………….76
Figure 5.9 Error page to show the failure of CSRF attack on buyshares.php…….....77
Figure 5.10 seride_log.txt file showing the CSRF attack origin information………..77
Figure 5.11 SA-SERIDE page to read the file name and domain name from
the user……………………………………………………………….....78
Figure 5.12 SA-SERIDE tool providing an option to select a file by directory
browsing………………………………………………………………...78
Figure 5.13 SA-SERIDE submit page to display the domain and selected
vii
file after directory browsing……………………………………….........79
Figure 5.14 SA-SERIDE tool output after passing buyshares.php file as input.........79
Figure 5.15 newbuyshares.php web page form (with inclusion of SERIDE code)…80
Figure 5.16 newbuyshares.php web page source code (with generated one-time
tokens) to protect from CSRF attacks…………………………………..80
Table 2.1 Example Token Table……………………………………………………..40
Table 4.1 Tested Applications……………………………………………………….58
viii
Nomenclature
Notation
Description
CSRF/XSRF
Cross Site Request Forgery
SERIDE SEession RIding DEfender
SA-SERIDE Semi-Automated SEession RIding DEfender
OWASP Open Web Application Security Project
PHP Hypertext PreProcessor
XSS Cross Site Scripting
HTML Hyper Text Markup Language
HTTP Hyper Text Transfer Protocol
URL Uniform Resource Locator
CAPTCHA Completely Automatic Public Turing Test to Tell
Computers and Humans Apart
NITK National Institute of Technology Karnataka
1
CHAPTER 1
INTRODUCTION
The web browser is a major application used to access search engines, community
websites, webmail’s, online banking, specific business applications for each sector,
etc from the private network or from Internet. They may contain sensitive data and
require an authentication step, or in the opposite be accessible to everyone. But all of
them can be accessed from a browser using standard protocols.
However, many web applications forget that HTTP requests they receive from
browsers may have been forged by another web page opened in the same browser
[13]. Without the user being aware of it, this malicious web page can take over his
identity and send a request to other website on his behalf. This kind of attack is called
Cross-Site Request Forgery (CSRF). This name was given by Peter Watkins in a June
2001 posting [14] to the Bugtraq mailing list.
CSRF exploits the HTTP protocol’s feature, that a webpage can include HTML
elements that will cause the browser to make requests to other websites. Like all
HTTP transactions, the requests to the other sites will include the user’s session
information such as cookies or HTTP integrated authentication if they have an
established session. Regardless of if the user has a session with the other sites,
elements of those sites will be loaded in the victim’s browser and can appear in the
browser’s cache and history. A CSRF can occur on an HTTP request using either the
GET or the POST method [15]. CSRF attacks generally target functions that cause a
state change on the server but can also be used to access sensitive data.
CSRF attack can be carried out in different ways. The attack could be done using a
HTML IMG Tag or a specially crafted URL embedded into the Target application.
This works for sure since the victim will be logged into the application. Another way
of doing it is to host a site/blog and influence the victim to visit the site. Many sites
can be used to host a CSRF including online forums (which often allow a user to link
to an image as an attachment), HTML email, photo galleries, wikis, blogs, online
auctions, and E-Commerce sites. CSRF attack using these sites might not work
2
always as users may not be currently logged into the target system when the exploit is
tried. CSRF flaws exist in the web applications with a predictable action structure and
which use the above credentials to authenticate users. Therefore, if the user is
currently authenticated to the site, the site will have no way to distinguish a malicious
request from a legitimate user request.
1.1 Motivation
The Open Web Application Security Project (OWASP) Top 10 report [4] lists the
following as the ten most critical web application security vulnerabilities that are been
exploited:
1. Cross Site Scripting (XSS)
2. Injection Flaws (SQL Injection, XPath Injection, LDAP Injection, etc)
3. Malicious File Execution
4. Insecure Direct Object Reference
5. Cross Site Request Forgery (CSRF)
6. Information Leakage and Improper Error Handling
7. Broken Authentication and Session Management
8. Insecure Cryptographic Storage
9. Insecure Communications
10. Failure to Restrict URL Access
Cross site request forgery attack is ranked at 5th
position in Open Web Application
Security Project (OWASP) top 10 web application threats in 2007. The CSRF attack
is severe web application vulnerability. According to rsnake, founder of ha.ckers.org,
there are too many CSRF vulnerabilities on the Internet to count [7]. The CSRF
attacks are typically 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. For
example, if the victim account has administrator rights, this can compromise the entire
web application.
Image based CSRF attacks are easy to exploit on the web applications. HTML image
elements and JavaScript image objects are the two most popular paths to CSRF.
3
There is no solution available to prevent CSRF attacks using IMG elements. The
IMG elements with static URLs (Uniform Resource Locator) have predefined
extensions (i.e. .jpg, .gif, .png, etc.) in their SRC attribute value (i.e. Uniform
Resource Identifier or URL), to retrieve the image. By validating the image
extensions in the web page source code, we can prevent the CSRF attacks using static
IMG elements.
The SERIDE [5] (SEssion RIding DEfender) is a PHP library code used to prevent
CSRF attacks. It is developed based on secret token validation mechanism. But the
current version (seride_v0.2) can be improved by making it as a semi-automated tool,
so that it will reduce burden to the administrator and he can include SERIDE token
functions efficiently in the PHP based web applications.
1.2 Implicit authentication
For most sites, after a successful initial authentication, web browsers will
automatically include any credentials associated with the site in further HTTP
requests without user interaction. This mechanism is called “implicit authentication”.
There are four distinct methods of implicit authentication such as HTTP
authentication credentials, session cookie, client side SSL authentication, IP address,
etc [1]. The short descriptions of these methods are as follows.
HTTP authentication: HTTP authentication [19] enables the web server to request
authentication credentials from the browser in order to restrict access to certain web
pages. There are three methods frequently used: Basic, digest and NTLM. In all these
cases the initial authentication process undergoes the same basic steps [20]. The steps
are:
1. The browser sends an HTTP request for a URL for which authentication is
required.
2. The web server answers with the status code “401 Unauthorized" causing the web
browser to demand the credentials from the user e.g. by prompting for username and
password.
4
3. After the user has supplied the demanded information, the web browser repeats the
HTTP request for the restricted resource. This request's header contains the user's
credentials in encoded form via the Authorization field.
4. The server validates whether the user is authorized. Depending on the outcome, the
server either answers with the requested page or again with a 401 status code.
The browser remembers the credentials for a certain time. If the client requests further
restricted resources that lie in the same authentication realm, the browser includes the
credentials automatically in the request.
Cookies: Web browser cookie technology [2] provides persistent data storage on the
client side. A cookie is a data set consisting at least of the cookie's name, value and
domain. It is sent by the web server as part of an HTTP response message using the
Set-Cookie header field (see Figure 1.1). The cookie's domain value is used to
determine in which HTTP requests the cookie is included. Whenever the web browser
accesses a webpage that lies in the domain of the cookie (the domain value of the
cookie is a valid domain suffix of the page's URL), the cookie is automatically
included in the HTTP request using the Cookie field. Cookies are often used as
authentication tokens by today's web applications. After a successful login procedure
the server sends a cookie to the client. Every following HTTP request that contains
this cookie is automatically regarded as authenticated.
Figure 1.1 Using cookies for client-side state
Of course, using cookies to store information is only suitable for data that may be
freely modified by the client. Because data is stored on the client’s machine, it is
under the user’s direct control. For some web applications, information must not be
5
modified between requests. In other cases, the amount of data that is associated with a
certain user is too large to constantly exchange it between the client and the server. To
address these issues, web applications typically make use of sessions.
A session is established to recognize requests that belong together, and to associate
these requests with (session) data stored at the server. To this end, each session is
assigned a unique identifier (the session ID), and the client is only provided with this
identifier. With each request, the client provides its ID (see Figure 1.2), which the
web application can subsequently use to retrieve the appropriate session data.
There are two possibilities to have the client attach the session IDs to each request.
The first possibility is to perform URL rewriting. In this case, hyperlinks and other
request triggers (such as HTML forms) are augmented with an additional parameter
that contains the session ID.
Figure 1.2 Using sessions for server-side state.
For instance, the hyperlink with the relative target location ./index.php might be
extended into ./index.php?sessid=12345 to store the session ID with the value
“12345”. The URL rewriting can be implemented by the application. However, many
application runtime and development environments (for example, PHP) already
provide an automatic rewriting mechanism to ease the task for web developers. The
second possibility to include session information is to set cookies, which are
automatically sent by the user browser with each request.
6
A convenient side-effect of sessions is that they can be used to track the
authentication state of a user. For instance, after a successful authentication of the
client, a web application could store a Boolean value auth=true for future reference.
When a user continues the current session by sending subsequent requests, the web
application can easily determine whether that user is already logged in by consulting
this Boolean value. As a result, the user is able to perform privileged actions without
the need to explicitly submit a password each time. Instead, the authentication occurs
implicitly by the underlying session mechanism. That is, the session ID serves as an
implicit authentication token.
Client side SSL authentication: The Secure Sockets Layer (SSL) and its successor the
Transport Layer Security (TLS) [8] protocols enable cryptographically authenticated
communication between the web browser and the web server. To authenticate the
communication partners X.509 certificates and a digital signature scheme are used
[21].
All these methods have in common, that after a successful initial authentication, the
web browser includes the authentication tokens (either the cookie, the http
authentication credentials or the SSL signature) automatically in further requests
without user interaction.
IP address based authentication: A special case of implicit authentication is often
found in intranets. Instead of actively requesting user authentication, the web
application passively uses the request's source IP address as authentication token, only
allowing certain IP (or MAC) addresses. Some intranet servers do not employ any
authentication at all because they are positioned behind the company's firewall. In this
case every web browser that is behind that firewall is authorized automatically.
Whatever the functionality the user can do on the website, the same can be performed
by an attacker by utilizing CSRF. This could include posting content to a message
board, subscribing to an online newsletter, logout, purchase item, change account
information or any other function provided by the vulnerable website. CSRF can also
be used as a vector to exploit existing Cross-site Scripting flaws in a given
application. For example if there is a XSS issue on an online forum or blog, an
7
attacker could force the user through CSRF to post a copy of the next big website
worm. An attacker could also utilize CSRF to relay an attack against a chosen site, as
well as perform a Denial of Service attack in the right circumstances [10]. CSRF
attacks can be successful against nearly every site that uses implicit authentication and
does not explicitly protect itself from CSRF attacks.
Synonyms: CSRF attacks are also known by a number of other names, including
XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, confused deputy,
and Hostile Linking [8]. Microsoft refers to this type of attack as a One-Click attack
in their threat modeling process and many places in their online documentation.
1.3 Types of CSRF attacks
CSRF vulnerabilities can be divided into two major categories [16]:
1. Stored CSRF and
2. Reflected CSRF
Stored CSRF: A stored CSRF vulnerability is one where the attacker can use the
application itself to provide the victim the exploit link or other content which directs
the victim’s browser back into the application, and causes attacker controlled actions
to be executed as the victim. If the application is vulnerable to CSRF, an attacker can
store the malicious code using IMG, IFRAME tag or XSS in a field that accepts
HTML. If the attacker can store a CSRF attack in the site, the severity of the attack is
high. The likelihood is increased because the victim is more likely to view the page
containing the attack than some random page on the Internet. Stored CSRF
vulnerabilities are more likely to succeed, since the user who receives the exploit
content is almost certainly authenticated to perform actions. Stored CSRF
vulnerabilities also have a more obvious trail, which may lead back to the attacker.
Reflected CSRF: In reflected CSRF vulnerability, the attacker uses a system outside
the application to expose the victim to the exploit link or content. This can be done
using a blog, an email message, an instant message, a message board posting, or even
an advertisement posted in a public place with an URL that a victim types in.
Reflected CSRF attacks will frequently fail, as users may not be currently logged into
8
the target system when the exploits are tried. The trail from a reflected CSRF attack
may be under the control of the attacker, however, and could be deleted once the
exploit was completed.
1.4 Working procedure of CSRF attack
Figures 1.3, 1.4 and 1.5 show the working procedure of CSRF attack [9].
Figure 1.3 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 authenticated session.
Figure 1.4 a valid request. The web browser attempts to perform a trusted action. The
trusted site confirms that the web browser is authenticated and allows the action to be
performed.
9
Figure 1.5 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.
1.5 Common ways to perform CSRF attacks
There are numerous ways in which an end-user can be tricked into loading
information from or submitting information to a web application. The most popular
ways to execute CSRF attacks is by using a HTML image tag, or JavaScript image
object [10]. Typically an attacker will embed these into an email or website so when
the user loads the page or email, they perform a web request to any URL of the
attackers liking. Below is a list of the common ways that an attacker may try sending
a request.
HTML Methods
IMG SRC
<img src="http://vulnerable_site/?command">
SCRIPT SRC
<script src="http:// vulnerable_site /?command">
IFRAME SRC
<iframe src="http:// vulnerable_site /?command">
JavaScript Methods
10
'Image' Object
<script>
var foo = new Image();
foo.src = "http:// vulnerable_site /?command";
</script>
'XMLHTTP' Object
IE
<script>
var post_data = 'name=value';
var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
xmlhttp.open("POST", 'http://url/path/file.ext', true);
xmlhttp.onreadystatechange = function () {
if (xmlhttp.readyState == 4)
{
alert(xmlhttp.responseText);
}
};
xmlhttp.send(post_data);
</script>
Mozilla
<script>
var post_data = 'name=value';
var xmlhttp=new XMLHttpRequest();
xmlhttp.open("POST", 'http://url/path/file.ext', true);
xmlhttp.onreadystatechange = function () {
if (xmlhttp.readyState == 4) {
alert(xmlhttp.responseText);
} };
xmlhttp.send(post_data);
</script>
Many other ways exist in HTML/VBScript/JavaScript/ActionScript/JScript and other
markup languages to make the users browser perform remote requests.
CSRF Exploitation Scenarios: In the following cases, CSRF attack is easier by
exploiting the vulnerabilities in the applications [16].
11
1. Many applications direct HTTP GET calls to the same handler that is used for
HTTP POST. This makes simpler image or link based exploits possible, and eases the
exploitation of CSRF flaws.
2. Some applications, particularly intranet sites and administrative consoles in
switches, access points, bridges, and other network devices uses integrated browser
authentication. This type of authentication doesn’t expire, and the credentials remain
available until the browser is closed. For someone who works with their browser all
day, this can be hours or even days. This is a very wide window for attack, and this
design decision increases the effectiveness of reflected CSRF attacks.
3. Many applications have extremely long cookie lives, allowing users to return to the
site without re-authenticating. Long session lives can expose users to the risk of CSRF
hours or even days after using a site. Popular sites with this configuration are of
course even worse as attackers can guess that a large number of people selected at
random are users of those services.
4. A few applications allow users to change their passwords without entering their old
password. If these password change mechanisms are vulnerable to CSRF, then
attackers may target this feature.
5. CSRF vulnerability is not limited to browsers [10]. An attacker could embed
scripting into a word document, Flash File, Movie, RSS or Atom web feed, or other
document format allowing scripting. Applications utilizing XML documents use
XML parsers to quickly parse through data. Certain tags within an XML document
may tell the XML parser to request additional documents from a URI. Browsers will
be the dominant way to execute these attacks but aren't the only way.
1.6 Example CSRF attacks
Let us consider the following examples:
Example 1: Let’s consider a hypothetical example of a site vulnerable to a CSRF
attack. This site is a web-based forum that allows users to send and receive messages.
The site uses implicit authentication to authenticate its users. One page,
http://example.com/send_msg.html, contains an HTML form allowing a user to enter a
12
recipient’s address (e-mail), subject, and message as well as a button that says, “Send
Message.”
<form action="http://example.com/send_msg.html" method="GET">
Recipient’s address: <input type="text" name="to">
Subject: <input type="text" name="subject">
Message: <textarea name="msg"></textarea>
<input type="submit" value="Send Message">
</form>
When a user of example.com clicks “Send Message”, the data he entered will be sent
to http://example.com/send_msg.html as a GET request. Since a GET request 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 subject,
and “What’s the status of the project?” as the message):
http://example.com/send_msg.html?to=bob%40example.com&subject=hello&msg=
What%27s+the+status+of+the+project%3F3
The page send_msg.html would take the data it received and send a message to the
recipient from the user. Note that send_msg.html simply takes data and performs 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 message. For example, if the user typed the
following three URLs into his browser, send_msg.html would send three messages
(one each to Bob, Alice, and Carol):
http://example.com/send_msg.html?to=bob%40example.com&subject=hi+Bob&
msg=test
http://example.com/send_msg.html?to=alice%40example.com&subject=hi+Alice&
msg=test
http://example.com/send_msg.html?to=carol%40example.com&subject=hi+Carol&
msg=test
A CSRF attack is possible here because send_msg.html takes any data it receives and
sends message. It does not verify that the data originated from the form on
compose.html. Therefore, if an attacker can cause the user to send a request to
13
send_msg.html, that page will cause example.com to send message on behalf of the
user containing any data of the attacker’s choosing and the attacker will have
successfully performed a CSRF attack.
To exploit this vulnerability, the attacker needs to force the user’s browser to send a
request to send_msg.html to perform some malicious activity. (We assume the user
visits a site under the attacker’s control and the target site does not defend against
CSRF attacks.) Specifically, 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_msg.html?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_msg.html, which will
then send an email to Mallory from the user.
Example 2: Consider a sample PHP application of buy shares. The form and its code
are as follows:
Buystocks.html
<html><body>
<form action="buy.php" method="POST">
Symbol<input type="text" name="symbol"/>
Shares:<input type="text" name="shares" />
<input type="submit" value="Buy" />
</form></body>
</html>
buy.php
<?php
session_start();
14
if (isset($_REQUEST['symbol']) && isset($_REQUEST['shares'])){
echo "the customer with reference ".$symbol." purchased ".$shares."shares <br />";
}
?>
The above form is vulnerable to CSRF attack even it uses the POST request for
submitting the form. An attacker can view the source of the form and he/she can do
forgery of the request and submit the form by using IMG tag. The sample code for
forging is as follows:
CSRF Attack by using IMG tag (Buyusingimg.html)
<html><body>
This is testing program to buy the shares when the token is present.<br>
<img src=”http://172.16.17.54/xamppwork/preventcsrf/tokenbasedeg/tokenbuy.php?
symbol=tokenrrr&shares=9999” width=”0” height=”0” />
</body></html>
Example 3: Stored CSRF attack example
If we consider the cmt.nitk.ac.in website forum maintained by NITK allowing the
registered users to post HTML messages as scraps to other users. This site is not
performing the input sanitization for the posted messages. So it is vulnerable to stored
CSRF attacks. If an attacker posts the following logout message as a discussion topic
in the forum, every user gets logged out immediately from the CMT (Course
Management Tool) site after logged into the site.
<IMG SRC=”http://cmt.nitk.ac.in/student/logout/logout.php” width=”0” height=”0”/>
If an attacker posts the following malicious message as a discussion topic, it will
increment the number of users visited counter for the user profile 07IS07 and make
this user as a most visited profile.
<img src=”http://cmt.nitk.ac.in/student/message/student_profile.php?regno=07IS07”
width="0" height="0" border="0"/>
Example 4: CSRF attack to logout from multiple websites
Using CSRF we can Logout from all Major Websites such as Gmail, Orkut etc. we
can easily get the logout URL’s of these websites by viewing its source code. After
15
finding all the URL’s, write a simple HTML file like the following. We can use the
HTML IMG element by setting its width and height attributes to 0 for not noticing it
to the victim.
Before executing this html code, victim should be authenticated to all or any of these
websites. Once the user is authenticated to a site, we can send this HTML file or URL
of the webpage which holds this malicious logout code. By doing social engineering
or posting this code in a vulnerable forum or blog we can perform this attack
successfully. If the most visited website allows html tags and script tags and which
allows users to post messages then we can do DoS (Denial of Service) attack on the
users using this logout vulnerability present in the major websites.
<HTML><BODY>
www.mail.google.com:
<IMG src="http://mail.google.com/mail/?logout&hl=en-GB" width="0" height="0"/>
www.mail.yahoo.com:
www.orkut.com:
<IMG src=http://www.orkut.com/GLogin.aspx?cmd=logout width="0" height="0"/>
www.m.indyarocks.com:
<IMG src=”http://www.indyarocks.com/mobile/logout.php" width="0" height="0"/>
<li>www.indyarocks.com <br></li>
<IMG src="http://www.indyarocks.com/logout.php" width="0" height="0"/>
www.sify.com
< IMG src=https://mail.google.com/a/sify.com/?logout&hl=en width=0 height=0/>
< IMG src="http://partnerpage.google.com/sify.com/default/logout?pid=sify.com
continue=http://partnerpage.google.com/sify.com&r=0" width=”0” height=”0”/>
< IMG src="http://webmail.sify.com/mail/?logout&hl=en" width="0" height="0" />
placement.nitk.ac.in:
<IMG src=http://placement.nitk.ac.in/student/logout/logout.php width=0 height=0/>
cmt.nitk.ac.in:
<IMG src="http://cmt.nitk.ac.in/student/logout/logout.php" width="0" height="0"/>
</BODY></HTML>
Example 5: Exploiting Session Mechanisms
16
The web application sessions imply that the session ID temporarily has the same
significance as the user’s original credentials. That is, as long as the session has not
expired, a web application treats requests with valid session IDs as requests of the
user who initially started the session. If an attacker manages to obtain the session ID
of an authenticated user, it is possible to issue requests with the same privileges as this
user. As a result, the session ID has become a primary target for web application
attacks. For instance, one of the goals of cross-site scripting (XSS) attacks is to inject
malicious JavaScript code into the reply of a vulnerable application with the aim to
leak the session ID to the attacker. In such attacks, the attacker abuses the fact that
web applications cannot reliably distinguish between requests with session IDs
originating from the legitimate user, and requests with stolen session IDs originating
from an attacker.
In contrast, cross-site request forgery (CSRF) is a relatively unknown form of attack
that is not motivated by the attempt to steal the session ID. Instead, XSRF attacks
abuse the fact that most web applications cannot distinguish between intended user
requests, and requests that the user issued because she was tricked to do so. For
instance, assume that the online banking application of www.bigbank.com receives the
following request from an authenticated user:
GET / transfer . php ? amount =10000& to =7777
The application interprets this as a request to transfer 10,000 USD from the user’s
bank account to the account with number 7,777. Since BigBank’s web application
does not take into account the possibility of XSRF attacks (unfortunately, this
problem is present in many other web applications), it optimistically assumes that the
request indeed originated from the HTML form designated for this purpose (shown in
Figure 1.6), and faithfully carries out the transaction. In reality, however, the GET
request was generated in the following way: After paying an invoice via online
banking, the user forgets to log out and proceeds by surfing to some other web sites.
One of these sites, evilxsrf.org, contains the following hyperlink:
<a href =’ www.bigbank .com/transfer.php?amount =10000? to =7777 ’ >
Click here </a> for something really interesting.
17
As soon as the user clicks on this link, the previously presented GET request is sent to
www.bigbank.com. Since the user forgot to log out, the session has not been
invalidated yet, and the cookie with the session ID still exists. As a result, the user’s
browser automatically appends the cookie to the request, which is successfully
authenticated by the banking application. Without intending so, the user has just
transferred a considerable amount of money to some unknown bank account.
Figure 1.6: Legitimate money transaction form of www.bigbank.com.
This, simple attack will probably work only against users that are not security-aware
and have limited knowledge about the mechanisms used in web applications. For
instance, the value of the href attribute will appear in the browser’s status bar as soon
as the user moves the mouse pointer above the link (although this could be avoided by
using JavaScript code that hides the status bar). Also, users become increasingly
aware of the security implications of clicking on links in mails. However, the critical
request can also be performed through the following src attribute of an image tag:
<img src =’ www . bigbank . com / transfer . php ? amount =10000? to =7777 ’ >
When the user visits the page containing this tag, the browser immediately attempts to
retrieve the image by sending the appropriate GET request to www.bigbank.com.
Compared to the previous case, the user did not even have to actively follow any link,
which clearly makes the attack more dangerous. Moreover, XSRF attacks are not
limited to GET requests. Figure 1.7 demonstrates how an equivalent POST request
can be assembled through an HTML form and automatically submitted by a short
piece of JavaScript code. Once again, visiting the malicious HTML page is sufficient
for the attack to succeed. Note that although disabling JavaScript would prevent the
automatic submission of the form in this case, this measure is not suitable as general
<form action =" transfer . php " method =" get ">
To: <input type =" text " name =" to "/>
Amount : <input type =" text " name =" amount "/>
<input type =" submit " value =" Submit "/>
</form >
18
cure against XSRF attacks. This underlines the fact that XSRF problems are
independent of XSS vulnerabilities and do not rely on the execution or injection of
malicious JavaScript code.
Figure 1.7: Malicious XSRF page for POST parameters.
The analysis of the mechanisms behind XSRF attacks leads to the following
observation: As long as a user is logged in to a web application, she is vulnerable. A
single mouse click or just browsing a page under the attacker’s control can easily lead
to unintended requests. Most web applications are not aware of this fact, leaving their
users in danger.
1.7 Real-world CSRF attacks
Several CSRF vulnerabilities against real-world web applications have been
discovered [6]. The most famous CSRF attack was the Samy worm on MySpace,
which blended a deadly cocktail of XSS and CSRF that eventually took down the site
[7]. The CSRF vulnerability in Gmail was discovered in late 2007 which allowed a
attacker to steal a Gmail user's contact list. When the Gmail user visited a malicious
site, the malicious site could generate a filter request to Gmail that Gmail treated as
part of its ongoing session with the victim and it forwarded the entire victim’s email
contact list to the attacker’s email address [12, 17].
The Vulnerability in Netflix allowed an attacker to change the name and address of
victim’s account or cancel his account, as well as add movies to the victim’s rental
queue [12]. In Jan, 2008, an e-mail with a malicious IMG tag was sent to victims. By
<form action =" http :// www . bigbank . com / transfer . php " method =" post ">
<input type =" hidden " name =" to" value ="7777"/ >
<input type =" hidden " name =" amount " value ="10000"/ >
<input type =" submit "/>
</form >
<script type =" text / javascript ">
document . forms [0]. submit ();
</ script >
19
accessing the image in the mail, the user initiated a router command to change the
DNS entry, making any subsequent access by a user to the bank goes through the
attacker's server [18].
About 18 million users of eBay's Internet Auction Co. at Auction.co.kr in Korea lost
personal information in February 2008. Customers of a bank in Mexico were attacked
in early 2008 with an image tag in email and were sent through their home routers to
the wrong website [12, 31].
In Sept, 2008 Bill zeller [9] found major CSRF vulnerabilities in 4 major web sites.
The vulnerabilities present in these sites allow an attacker to transfer funds out of
user’s bank accounts (ING Direct), add videos to a user’s “QuickList” (YouTube),
and take control of user’s account (MetaFilter) and to find out the email address of an
arbitrary user (The New York Times). All the above vulnerabilities in 4 major sites
have been fixed.
1.8 Login CSRF
Login CSRF is a new variation on CSRF attacks, in which an attacker uses the
victim's browser to forge a cross-site request to the honest site's login URL, supplying
the attacker's user name and password. If the forgery succeeds, the 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. This
session cookie is used to bind subsequent requests to the user's session and hence to
the attacker's authentication credentials. Many web sites, including Yahoo, PayPal,
and Google, were vulnerable to login CSRF. The impact of login CSRF attacks vary
by site, ranging from allowing the attacker to mount XSS attacks on Google to
allowing the attacker to obtain sensitive financial information from PayPal [3].
Search History. Many search engines, including Yahoo! and Google, allow their users
to opt-in to saving their search history and provide an interface for a user to review his
or her personal search history. Search queries contain sensitive details about the user's
interests and activities and could be used by an attacker to embarrass the user, to steal
the user's identity, or to spy on the user. An attacker can spy on a user's search history
by logging the user into the search engine as the attacker; see Figure 1.8. The user's
20
search queries are then stored in the attacker's search history and the attacker can
retrieve the queries by logging into his or her own account.
PayPal. PayPal lets its users transfer funds to each other. To fund a PayPal account,
users enroll their credit card or their bank account. A web attacker can use login
CSRF to mount the following attack:
1. The victim visits a malicious merchant's site and chooses to pay using PayPal.
2. As usual, victim is redirected to PayPal and logs into his or her account.
3. The merchant silently logs the victim into his or her PayPal account.
4. To fund her purchase, the victim enrolls his or her credit card, but the credit card
has actually been added to the merchant's PayPal account.
Figure 1.8 Event trace diagram for a login CSRF attack. The victim visits the
attacker's site, and the attacker forges a cross-site request to Google's login form,
causing the victim to be logged into Google as the attacker. Later, the victim makes a
web search, which is logged in the attacker's search history [3].
21
1.9 CSRF Vs XSS
Cross-Site Scripting (XSS) and CSRF attacks are frequently confused as they are
clearly related [13]. Both attacks are aimed at the user and often require the victim to
access a malicious web page. Also the potential consequences of the two attack
vectors can be similar: The attacker is able to submit certain actions to the vulnerable
web application using the victim's identity. The causes of the two attack classes are
different though. A web application that is vulnerable to XSS fails to properly sanitize
user provided data before including this data on a webpage, thus allowing an attacker
to include malicious JavaScript in the web application. This JavaScript consequently
is executed by the victim's browser and initiates the malicious requests. XSS attacks
have more capabilities beyond the creation of http request and are therefore more
powerful than CSRF attacks: A rogue JavaScript has almost unlimited power over the
webpage it is embedded in and is able to communicate with the attacker. A XSS can
e.g. obtain and leak sensitive information.
Cross Site Scripting (XSS) exploits the trust that a client has for the website or
application. Users generally trust that the content displayed in their browsers was
intended to be displayed by the website being viewed. In contrast, CSRF exploits the
trust that a site has for the user. The website assumes that if an 'action request' was
performed, it trusts that the request is being sent by the user [10].
An attacker exploits a lack of input and / or output filtering in the case of XSS flaw.
Filter out the dangerous characters like <, >, “, ‘, &, ;, or # in an application could
resolve the XSS flaw. XSS is related to the application performing insufficient data
validation. XSS flaws may allow bypassing of any CSRF protections by leaking valid
values of the tokens, allowing Referrer headers to appear to be the application itself,
or by hosting hostile HTML and JavaScript elements right in the target application.
Therefore resolving XSS flaws should be given priority over CSRF weaknesses [16].
XSS aimed at inserting active code in an HTML document to either abuse client-side
active scripting holes, or to send privileged information (e.g. authentication/session
cookies) to a attacker controlled site. CSRF does not in any way rely on client-side
active scripting, and its aim is to take unwanted, unapproved actions on a site where
22
the victim has some prior relationship and authority. Where XSS sought to steal the
online trading cookies so an attacker could manipulate the victim’s portfolio, CSRF
seeks to use the victim’s cookies to force the victim to execute a trade without his
knowledge or consent.
1.10 Organization of the Thesis
The thesis is organized into the following six chapters.
• Chapter 1 is the introduction chapter and explains the basics of Cross Site
Request Forgery attacks.
• Chapter 2 presents the existing CSRF defensive mechanisms and the existing
tools for preventing CSRF attacks.
• Chapter 3 presents the project problem statement.
• Chapter 4 contains the detailed description of our implemented solution to
prevent Image based CSRF attacks.
• Chapter 5 contains the detailed description of the SERIDE code and the semi-
automation of the SERIDE (SA-SERIDE) Tool.
• Chapter 6 gives the conclusion and recommendations for future research.
• Appendix gives the detailed description of tools used in this project.
23
CHAPTER 2
EXISTING CSRF DEFENSES
In contrast to XSS (Cross-site scripting) and SQL injection attacks, CSRF attack is
little-known to the web application developers and academic community [2]. As a
result, few mitigation solutions exist but these do not offer complete protection
against CSRF attacks, or require modifications to the existing web applications that
should be protected. This chapter presents the existing defensive mechanisms and
tools to mitigate the cross site request forgery attacks.
2.1 Existing CSRF defensive mechanisms
There are few mechanisms a site can use to defend itself against CSRF attacks:
validating a secret token, validating the HTTP Referer header, including additional
headers with XMLHttpRequest, and Origin header. None of these mechanisms
completely defend against CSRF attacks [3].
2.1.1 Secret Validation Token
One approach to defend against CSRF attacks is to send additional information in
each HTTP request that can be used to determine whether the request came from an
authorized source. This “validation token" should be hard to guess for an attacker who
does not already have access to the user's account. If a request is missing a validation
token or the token does not match the expected value, the server will reject the
request.
Random form tokens: To prevent CSRF attacks, a web application has to make sure
that the incoming form data is originated from a valid HTML form. “Valid" in this
context denotes the fact that the submitted HTML form was generated by the actual
web application in the first place. It also has to be ensured that the HTML form was
generated especially for the submitting client. To enforce these requirements, hidden
form elements with random values can be employed. These values are used as one
time tokens [1]: The triplet consisting of the form's action URL, the ID of the client
(e.g. the session ID) and the random form token are stored by the web application.
24
Whenever form data is submitted, the web application checks if this data contains a
known form token which was stored for the submitting client. If no such token can be
found, the form data has been generated by a foreign form and consequently the
request will be denied.
Using explicit authentication: There are methods to communicate authentication
tokens explicitly: Authentication tokens can be included into the web application's
URLs or transported via hidden fields in HTML forms. These techniques are resistant
to CSRF attacks.
Token Designs: There are number of techniques for generating and validating tokens.
Session Identifier: The browser's cookie store is designed to prevent unrelated
domains from gaining access to each other's cookies. One common design is to use
the user's session identifier as the secret validation token. On every request, the server
validates that the token matches the user's session identifier. An attacker who can
guess the validation token can already access the user's account. One disadvantage of
this technique is that, occasionally, users reveal the contents of web pages they view
to third parties, for example via email or uploading the web page to a browser
vendor's bug tracking database. If the page contains the user's session identifier in the
form of a CSRF token, anyone who reads the contents of the page can impersonate the
user to the web site until the session expires.
Session-Independent Nonce: Instead of using the user's session identifier, the server
can generate a random nonce and store it as a cookie when the user first visits the site.
On every request, the server validates that the token matches the value stored in the
cookie. This approach fails to protect against active network attackers, even if the
entire web application is hosted over HTTPS, because an active network attacker can
overwrite the session-independent nonce with his or her own CSRF token value and
proceed to forge a cross-site request with a matching token.
Session-Dependent Nonce: A refinement of the nonce technique is to store state on
the server that binds the user's CSRF token value to the user's session identifier. On
every request, the server validates that the supplied CSRF token is associated with the
25
user's session identifier. This approach is used by CSRFx [22], CSRFGuard [23], and
NoForge [2] but has the disadvantage that the site must maintain a large state table in
order to validate the tokens.
HMAC of Session Identifier: Instead of using server-side state to bind the CSRF token
to the session identifier, the site can use cryptography to bind the two values. For
example, the Ruby on Rails web application framework implements this technique
and uses the HMAC of the session identifier as a CSRF token. As long as all the site's
servers share the HMAC key, each server can validate that the CSRF token is
correctly bound to the session identifier. Properties of HMAC ensure that an attacker
who learns a user's CSRF token cannot infer the user's session identifier.
Given sufficient engineering resources, a web site can use the HMAC technique to
defend itself against CSRF attacks. However, many web sites and CSRF defense
frameworks (such as NoForge [2], CSRFx [22] and CSRFGuard [23]), fail to
implement the secret token defense correctly. One common mistake is to leak the
CSRF token during cross-site requests. For example, if the honest site appends the
CSRF token to hyperlinks another site, that site gains the ability to forge cross-site
requests against the honest site.
Case Study: NoForge. NoForge [2] implements CSRF defense using secret validation
token bound to the session identifier using server-side state. Instead of modifying the
web application to handle the CSRF token, NoForge parses the site's HTML as it is
serialized onto the network and appends the CSRF token to all hyperlinks and form
submissions.
Drawback: The drawback of this approach is the considerable amount of manual
work that it involves. Many current web applications have evolved into large and
complex systems, and retrofitting them with the mechanisms necessary for token
management would require detailed application-specific knowledge and considerable
modifications to the application source code. Even more important, there is no
guarantee that the modified code is indeed free of CSRF vulnerabilities, as developers
tend to make errors and omissions.
26
2.1.2 The Referer Header
An HTTP request's Referer indicates the URL of the webpage that contained the
HTML link or form that was responsible for the request's creation. The Referer is
communicated via an HTTP header field. The Referer header, if present, distinguishes
a same-site request from a cross-site request because the header contains the URL of
the site making the request. A site can defend itself against cross-site request forgery
attacks by checking whether the request in question was issued by the site itself. If
this is not the case, the request is usually rejected.
Unfortunately, the Referer contains sensitive information that impinges on the privacy
of web users [24]. For example, the Referer header reveals the contents of the search
query that lead the user to visit a particular site. Although this information is useful to
web site owner, who can use the information to optimize their search engine rankings,
this information disclosure leads some users to feel their privacy has been violated.
Additionally, many organizations are concerned that confidential information about
their corporate intranets might leak to external web sites via the Referer header.
Bugs: Historically, browsers and have contained vulnerabilities that let malicious web
sites spoof value of the Referer header, especially in conjunction with proxy servers.
Discussions of Referer spoofing often cite [25] as evidence that, browsers permit the
Referer header to be spoofed. Mozilla has patched the Referer spoofing vulnerabilities
in Firefox 1.0.7 [26]. These vulnerabilities affect only XMLHttpRequest and can be
used only to spoof Referers directly back to the attacker's own site.
Strictness: If a site elects to use the Referer header to defend against CSRF attacks,
the site's developers must decide whether implement lenient or strict Referer
validation.
In lenient Referer validation, the site blocks requests whose Referer header has an
incorrect value. If a request lacks the header, the site accepts the request. Although
widely implemented, lenient Referer validation is easily circumvented because a web
attacker can cause the browser to suppress the Referer header [1]. For example,
requests issued from ftp and data URLs do not carry Referer headers.
27
In strict Referer validation, the site also blocks requests that lack a Referer header.
Blocking requests that lack a Referer header protects against malicious Referer
suppression but incurs a compatibility penalty as some browsers and network
configurations suppress the Referer header for legitimate requests.
Case Study: Facebook. Throughout the majority of its site, Facebook uses secret
token validation to protect against CSRF. Facebook's login form, however, uses
lenient Referer validation to defend against CSRF attacks. This approach to login
CSRF protection is ineffective against web attackers. For example, a web attacker can
redirect the user from http://attacker.com/ to ftp://attacker.com/index.html and then
issue a cross-site login request to Facebook. Because it originates from an ftp URL,
none of the major browsers send a Referer header.
The conclusions about the usage of Referer header are:
1. CSRF Defense over HTTPS: The Referer header can be used as a CSRF defense
for HTTPS requests. In order to use the Referer header as a CSRF defense, a site must
reject requests that omit the header because an attacker can cause the browser to
suppress the header. Over HTTP, sites cannot afford to block requests that lack a
Referer header because they would cease to be compatible with the sizable percentage
of users. Over HTTPS, however, strict Referer validation is feasible because only a
tiny percentage of browsers suppress the header.
2. Privacy Matters: Strict Referer validation is an appealing CSRF defense because
the defense is simple to implement. Unfortunately, the poor privacy properties of the
Referer header hamper attempts to use the header for security over HTTP. New
browser security features, including new CSRF defense mechanisms, must address
privacy concerns in order to be effective in large-scale deployments.
Some users prohibit their web browsers to send Referer information because of
privacy concerns. For this reason web applications have to accept requests that do not
carry Referer information. Otherwise they would exclude a certain percentage of
potential users from their services. It is possible for an attacker to reliably create
Refererless requests. For this reason any web application that accepts requests without
Referers cannot rely on Referer checking as protection against CSRF.
28
There are different methods [1] to create HTTP hidden requests that do not produce
referers in a victim’s browser. Depending on the web browser the victim uses, one or
more of these methods are applicable by the attacker.
1. Page refresh via meta tag: This method employs the “HTTP-EQUIV =Refresh"
meta tag. The tag specifies a URL and a timeout value. If such a tag is found in the
“head" section of an HTML document, the browser loads the URL after the given
time. Example:
<META HTTP-EQUIV=Refresh CONTENT="0; URL=http://path to victim">
On some web browsers the http GET request, which is generated to retrieve the
specified URL, does not include a referer. It is not possible to create POST request
this way.
2. Dynamically filled frame: To generate hidden POST requests, the attacker can use
an HTML form with proper default values and submit it automatically with
JavaScript. To hide the form's submission the form is created in an invisible frame. As
long as the src attribute of the frame has not been assigned a value, the refering
domain value stays empty. Therefore the form cannot be loaded as part of a
predefined webpage. It has to be generated dynamically. The creation of the form
elements is done via calls to the frames DOM tree.
3. Pop under window: The term “pop under" window denotes the method of opening
a second browser window that immediately sends itself to the background. On
sufficiently fast computers users often fail to notice the opening of such an unwanted
window. Such a window can be used to host an HTML form that is submitted either
automatically or by tricking the victim to click something. The form can be generated
by calls to the DOM tree or by loading a prefabricated webpage. Depending on the
victim's browser one of these methods may not produce a referer.
4. The Referer header mechanism fails due to the possibility to spoof the referers and
make them appear to be correct. The following PHP code shows an implementing
example of HTTP Referer [28]:
<!-- check.php -->
if(eregi("www.nitk.ac.in", $_SERVER['HTTP_REFERER'])) {
do_something();
29
} else {
echo "Malicious Request!";
}
This check can be easily bypassed forging a fake HTTP Referer from the attacker's
script using something like:
header("Referer: www.nitk.ac.in");
Or any other way to forge the Headers to be sent from the malicious script. Since the
HTTP Referer is sent by the browser and not controlled by the server so we should
never consider this variable as a trusted source.
2.1.3 Custom HTTP Headers
Custom HTTP headers can be used to prevent CSRF because the browser prevents
sites from sending custom HTTP headers to another site but allows sites to send
custom HTTP headers to themselves using XMLHttpRequest. For example, the
prototype.js JavaScript library [27] uses this approach and attaches the X-Requested-
By header with the value XMLHttpRequest. Google Web Toolkit also recommends
that web developers defend against CSRF attacks by attaching a X-XSRF-Cookie
header to XMLHttpRequest that contains a cookie value. The cookie value is not
actually required to prevent CSRF attacks: the mere presence of the header is
sufficient.
To use custom headers as a CSRF defense, a site must issue all state-modifying
requests using XMLHttpRequest, attach the custom header (e.g., X-Requested-By),
and reject all state-modifying requests that are not accompanied by the header. For
example, to defend against login CSRF, the site must send the user's authentication
credentials to the server via XMLHttpRequest.
2.1.4 Origin Header
To prevent CSRF attacks, browsers send Origin header with POST requests that
identifies the origin that initiated the request. If the browser cannot determine the
origin, the browser sends the value null.
30
Privacy: The Origin header improves on the Referer header by respecting the user's
privacy:
1. The Origin header includes only the information required to identify the principal
that initiated the request (typically the scheme, host, and port of the active document's
URL). In particular, the Origin header does not contain the path or query portions of
the URL included in the Referer header that invade privacy without providing
additional security.
2. The Origin header is sent only for POST requests, whereas the Referer header is
sent for all requests. Simply following a hyperlink (e.g., from a list of search results or
from a corporate intranet) does not send the Origin header, preventing the majority of
accidental leakage of sensitive information.
By responding to privacy concerns, the Origin header will likely not be widely
suppressed.
Server Behavior: To use the Origin header as a CSRF defense, sites should behave as
follows:
1. All state-modifying requests, including login requests, must be sent using the POST
method. In particular, state-modifying GET requests must be blocked in order to
address the forum poster threat model.
2. If the Origin header is present, the server must reject any requests whose Origin
header contains an undesired value (including null). For example, a site could reject
all requests whose Origin indicated the request was initiated from another site.
2.1.5 CAPTCHAs
Another technique for mitigating CSRF is to require the user to solve a CAPTCHA
before allowing an important request to proceed [3]. Using a random CAPTCHA
image in every form which require the user to type in a textbox the generated string
and with that verify the integrity of the submitted data and the credentials of the user
can prevent the CSRF attacks [28]. Although CAPTCHAs have many other
applications, they offer few advantages over secret validation tokens as a CSRF
defense. If it is known to the attacker which CAPTCHA is displayed, then the attacker
can manually solve CAPTCHAs and attack one user per CAPTCHA solved, which is
31
expensive but probably still cost-effective. If the decision of which CAPTCHA to
display is a session-dependent secret, then this information could be used as a session-
dependent secret validation token without burdening the user with the task of solving
a CAPTCHA. This solution has been discarded some time ago due to the possibility
to retrieve the captcha image using the so called MHTML bug, which affected several
versions of Microsoft Internet Explorer [29].
2.2 Prevention measures that do NOT work
There exist misconceptions about possibilities to protect web applications against
CSRF attacks [4]. These are the preventive measures that do not protect the websites
against CSRF attacks.
2.2.1 Secret cookie
Remember that all cookies, even the secret ones, will be submitted with every request.
All authentication tokens will be submitted regardless of whether or not the end-user
was tricked into submitting the request. Furthermore, session identifiers are simply
used by the application container to associate the request with a specific session
object. The session identifier does not verify that the end-user intended to submit the
request.
2.2.2 Accepting only HTTP POST requests
Applications can be developed to only accept POST requests for the execution of
business logic. A frequent assumption is, that a web application which only accepts
form data from http POST request is protected against CSRF, as the popular attack
method of using IMG tags only creates http GET requests. The misconception is that
since the attacker cannot construct a malicious link, a CSRF attack cannot be
executed. Unfortunately, this logic is incorrect. There are numerous methods in which
an attacker can trick a victim into submitting a forged POST request, such as a simple
form hosted in attacker's website with hidden values. Hidden POST requests can be
created e.g. by using HTML forms in invisible iframes, which are automatically
submitted via JavaScript.
32
2.2.3 URL rewriting
In the case of URL rewriting, on the other hand, the session ID has to be embedded
into the request trigger (e.g., a hyperlink or a form) explicitly. Thus, when the attacker
attempts to create a page with a hyperlink that performs the XSRF request, this link
will not contain the proper session ID and thus, will not result in a successful attack.
Of course, the adversary cannot prepare the link with a correct session ID, because he
has no knowledge about this identifier; otherwise he could use this ID directly to
impersonate the authenticated user.
The problem is that cookie-based session management is much more popular and
wide-spread for a number of reasons, some of which are even security related [2]. For
example, in URL-based solutions, the session ID appears in the browser’s location
bar. One implication is that a user might bookmark a page together with the session
ID. When visiting the web site via this bookmark, the web server might again
associate the session with this ID (this type of session management is called
permissive and is present, for example, in PHP). As a result, one session ID is used
for multiple sessions, increasing the chances for an attacker to successfully steal and
exploit the ID. Another possibility is that an attacker could simply peek over a
victim’s shoulder to steal the session ID (e.g., in a public Internet cafe).
2.3 Partial solutions to limit the risks of CSRF attacks
Cross site request forgery is severe web application vulnerability. User awareness of
the dangers it presents and how to protect themselves from exploits is a good first
step. The exploit is delivered to the user in various ways. Attack vectors include e-
mail and tricking users to click on a link at the attacker's site. Once the exploit is
launched, it relies on an existing trusted session with the target site or the presence of
an auto-logon cookie on the victim's PC. If a trusted session is available, the exploit
commands are run on the site server within the victim's security context. Defending
against CSRF attacks is difficult, but not impossible. The best defense for users is to
take the proper steps to ensure trusted sessions can't be used by cybercriminals. Here
are partial solutions to limit the risks of CSRF attacks [13, 14]:
33
User awareness: Users should be aware that a web page can contain malicious code,
which could interact with another web application and then take over their identity.
That’s why users who log in a sensitive application (online banking, etc) should:
• Ideally, close any running browser instance and check in the task manager that
any corresponding processes have been killed. Or at least, they should close
any browser windows whose content is not trusted;
• Check whether the address bar displays the address of the visited site and
whenever possible, they should manually rewrite the address to be sure of the
web site authenticity.
However, these recommendations are difficult to accept for most users.
• It is not actually possible to restrict HTTP requests used by image tags or
forms. This functionality is needed by most web applications (advertisements,
mashups, etc). The display of a warning message when suspicious request is
performed by a script, like Internet Explorer 7.0 does, may be an interesting
idea and could limit the number of successful CSRF attacks. However, some
users will always accept dangerous scripts.
• Do not use an email client that renders HTML.
• Do not use a newsgroup client tied to your Web browser.
• Do not allow your browser to save usernames/passwords.
• Do not ask Web sites you care about to "remember" your login.
• Be sure to log out of trusted sessions when finished.
• Be cautious when asking a site to remember your user and password on login.
This may deposit login information on the client that can be exploited.
• Delete all cookies after a trusted session.
• Site developers have a bigger challenge when attempting to write applications
that are less susceptible to CSRF. The following is a list of countermeasures to
consider:
• Set a short time period for trusted user sessions.
• Verify the user making the request each time a trust-based action is requested.
• Per-request nonces added to URLs and forms provide per request user
verification beyond the basic session token.
34
• Eliminate all XSS vulnerabilities from applications. XSS can be used to obtain
useful attack information. For example, an attacker could fake a form that
prompts the user for identity information.
2.4 Existing tools for preventing CSRF attacks
This section explains about the existing ‘RequestRodeo’ and ‘NoForge’ tools
developed for preventing CSRF attacks. RequestRodeo is a client-side proxy based
solution to prevent CSRF attacks and works by disabling the automatism of adding
authentication information to each request. NoForge is a server-side proxy that is able
to defend PHP applications against CSRF attacks in a way that is transparent to users
as well as to the web application itself. This proxy is able to inspect and modify client
requests as well as the application’s replies (output) to automatically and transparently
extend applications with the shared secret technique (i.e. secret token validation
mechanism). The detailed discussion on these tools is as follows.
2.4.1 RequestRodeo: Client side protection against CSRF attacks
RequestRodeo is the first client-side solution for protection against CSRF attacks [1].
This solution works as a local proxy on the user’s computer.
Concept: The fundamental mechanism that is responsible for CSRF attacks to be
possible is the automatic inclusion of authentication data in any HTTP request that
matches the authentication data's scope. RequestRodeo solution is to partly disable the
automatism that causes the sending of the authentication data. The proxy identifies
HTTP requests which qualify as potential CSRF attacks and strips them from all
possible authentication credentials. This solution is implemented in the form of a
proxy instead of integrating it directly into web browser technology to enable CSRF
protection for all common web browsers.
Identification of suspicious requests: The proxy resides between the client's web
browser and the web application's server. Every HTTP request and response is routed
through the proxy. Because of the fact that the browser and the proxy are separate
entities, the proxy is unable to identify how an HTTP request was initiated. The
35
following classification is used to decide if an HTTP request is legitimate or
suspicious of CSRF:
Definition 1 (entitled): An HTTP request is classified as entitled only if:
- It was initiated because of the interaction with a web page (i.e. clicking on a link,
submitting a form or through JavaScript) and
- The URLs of the originating page and the requested page satisfy the “same-origin
policy". This means that the protocol, port and domain of the two URLs have to
match.
Only requests that were identified to be entitled are permitted to carry implicit
authentication information.
To determine if a request can be classified as entitled, the proxy intercepts every
HTTP response and augments the response's HTML content. Every HTML form, link
and other means of initiating HTTP requests is extended with a random URL token.
Furthermore the tuple consisting of the token and the response's URL is stored by the
proxy for future reference. From now on, this token allows the proxy to identify
outgoing HTTP requests with prior HTTP responses. Every request is examined
whether it contains a URL token. If such a token can be found, the proxy compares
the token value to the values which have been used for augmenting prior HTTP
responses. This way the proxy is able to determine the URL of the originating HTML
page. By comparing it with the request's URL, the proxy can decide if the criteria
defined in definition 1 are met. If this is not the case, all implicit authentication
information is removed from the request.
Removal of authentication credentials: there are two different methods of implicit
authentication used by today's web applications that include credentials in the HTTP
header: http authentication and cookies. If the proxy encounters an HTTP request, that
cannot be classified as entitled, the request is examined if its header contains Cookie
or Authorization fields. If such header fields are found, the proxy triggers a
reauthentication process. This is done either by removing the Cookie header field or
by ignoring the Authorization field and requesting a reauthentication before passing
the request on to the server. Following the triggered reauthentication process, all
36
further requests will be entitled as they originated from a page that belongs to the web
application (beginning with the webpage that executed the reauthentication).
RequestRodeo was implemented using Python programming language with the
Twisted framework. The approach is as follows:
Augmenting the response’s HTML content: the proxy intercepts the server’s HTTP
response and scans the HTML content for URLs. Every URL receives an additional
GET parameter called _rrt (for “RequestRodeoToken”). Furthermore JavaScript code
that may initiate HTTP requests is altered: the proxy appends a JavaScript function
called addToken() to the webpage’s script code. This function assumes that its
parameter is a URL and adds the GET token to this URL. This alteration of URLs that
are processed by JavaScript is done dynamically because such URLs are often
assembled on script execution and are therefore hard to identify reliably otherwise.
Removal of header located authentication credentials: the following aspects had to be
taken into consideration:
Cookies: If a cookie header field is found in a suspicious request, it is deleted before
the request is passed to the server. To ensure compatibility with common web
applications, this solution somewhat relaxes the requirements of Definition 1: the
proxy respects a cookie’s domain value. A cookie is therefore only discarded if its
domain does not match the domain of the referring page. Otherwise e.g. a cookie that
was set by login.example.org with the domain value “.example.org” would be deleted
from requests for order.example.org.
HTTP authentication: Simply removing the authorization data from every request that
has not been classified as entitled is not sufficient. The proxy cannot distinguish
between a request that was automatically supplied with an Authorization header and a
request that reacts to a 401 status code. As the web browser, after the user has entered
his credentials, simply resends the http request that has triggered the 401 response, the
resulting request is still not entitled because its URL has not changed. Therefore the
proxy has to uniquely mark the request's URL before passing it on to the server.
This way the proxy can identify single requests reliably. It is therefore able to
determine if an Authorization header was sent because of a “401 Unauthorized"
message or if it was included in the message automatically without user interaction.
37
Whenever the proxy receives a request, that was not classified as entitled and contains
an Authorization header, the following steps are executed (see Figure 2.1):
1. The proxy sends a “302 temporary moved" response message. As target URL of
this response the proxy sets the original request's URL with an added unique token.
2. The client receives the “temporary moved" response and consequently requests the
URL that was provided by the response.
3. The URL token enables the proxy to identify the request. The proxy ignores the
Authorization header and immediately replies with a “401 Unauthorized" message,
causing the client browser to prompt the user for username and password.
Furthermore the proxy assigns the status entitled to the URL/token combination.
4. After receiving the authentication information from the user, the client resends the
request with the freshly entered credentials.
5. As the request now has the status entitled, the proxy passes it on to the server. An
analog process has to be performed, whenever a not entitled request triggers a “401
Unauthorized" response from the server.
Figure 2.1 Intercepting implicit HTTP authentication
Usage of an outside entity to prevent IP based attacks: As described earlier, in
intranet scenarios the possession of a local IP address is often considered to be
sufficient authentication. For this reason, the proxy has to make sure that the target of
38
a request, that was not classified as entitled, is accessible from any host on the
internet. We introduce a reflection service that is installed on a host outside of the
cooperate intranet. The URL of every questionable request is submitted to this
service. The reflection service poses a HEAD request for the URL. If this request
succeeds, it is safe to assume that no IP based authentication mechanism is in place.
The outcome of this test is communicated back to the proxy. If the reflection service
was not able to access the URL, the proxy withholds the http request and replies with
a confirmation dialog instead. Only if the user explicitly confirms his intend of
requesting the protected content, the request is passed on to the server.
For performance reasons, the proxy keeps track of all IP addresses that were checked
this way. Every IP address is therefore only checked once, as long as the user's IP
address does not change. The reflection server will be distributed together with the
proxy to enable privacy conscious users to set up their own service.
Notification: Whenever the proxy removes implicit authentication credentials, an
unobtrusive notification element is added to the http response's HTML content in
order to notify the user about the proxy's action. In our prototype this is done via a
small floating sign.
Limitations: This solution cannot protect from “local" CSRF attacks. The local CSRF
attacks denote attacks that have their origin on the attacked web application. If e.g. an
application allows its users to post images to one of the application's web pages, a
malicious user may be able to use the image's URL to launch a CSRF attack. The
proxy would consider the image request as entitled as the image is referenced by a
webpage that belongs to the application.
As mentioned above, this solution is furthermore not able to prevent CSRF attacks on
client side SSL authentication. This issue could be solved, if the proxy instead of the
browser would handle the client side SSL authentication. Some web pages use
JavaScript to create parts of the page's HTML code locally. As JavaScript is a highly
dynamic language, the current implementation may fail in some cases to correctly
classify all included URLs as entitled. For this reason, the implementation of strict
referrer checking is considered as a second line of defense in certain cases. This
solution is designed to interfere as little as possible with a user's browsing.
39
2.4.2 NoForge
NoForge [2] implements CSRF defense using secret validation token bound to the
session identifier using server-side state. Instead of modifying the web application to
handle the CSRF token, NoForge parses the site's HTML as it is serialized onto the
network and appends the CSRF token to all hyperlinks and form submissions.
NoForge is a server-side proxy that is able to defend PHP applications against CSRF
attacks in a way that is transparent to users as well as to the web application itself.
This proxy is located between the web server and the protected web applications. One
important advantage of this approach is that there is only minimal manual effort
required to protect existing applications. To realize this in a straightforward fashion,
the proxy is implemented as wrapper functions around those PHP applications that are
intend to protect. These wrapper functions check the input and output of the
application and perform the necessary request and reply processing.
A Proxy-Based Solution
In this approach, a proxy is placed on the server side between the web server and the
target application (see Figure 2.2). This proxy is able to inspect and modify client
requests as well as the application’s replies (output) to automatically and transparently
extend applications with the shared secret technique (i.e. secret token validation
mechanism).
Figure 2.2 Placement of the CSRF proxy.
In particular, the proxy has to
- ensure that replies to an authenticated user are modified in such a way that future
requests originating from this document (i.e. through hyperlinks and forms) will
contain a valid token, and
- take countermeasures against requests from authenticated users that do not contain a
valid token.
40
An essential prerequisite for this mechanism is the proxy’s ability to associate a user’s
session with a valid token. To this end, the proxy maintains a token table that maps
session IDs to tokens (an example is shown in Table 2.1).
Table 2.1 Example Token Table.
By decoupling the proxy from the actual application, the CSRF protection can be
offered transparently for (virtually) all applications. Note that, alternatively, this
proxy could also be located between the client and the web server. However, this case
could lead to problems in combination with SSL connections. With this architecture,
SSL issues are directly handled by the web server, which eases the tasks that are to be
performed by the proxy.
A more detailed description of how requests to and replies from the web application
are handled, along with illustrative examples are discussed below.
Request Processing
Figure 2.3 provides an overview of the steps that the proxy has to take during request
processing. As a first step, we can check whether the request contains a session ID or
not. If there is no session ID in the request, it is classified as benign. The reason is that
since the request does not refer to an existing, authenticated session, it is not able to
perform any privileged actions. Thus, we can safely pass the request to the target
application.
Figure 2.3 Request processing.
41
If the request does contain a session ID, we consult the token table to check whether
there already exists an entry with a corresponding token. If there is such an entry, we
require that the request also contains this token. A request that fails to satisfy this
condition is classified as a CSRF attack. This is because legitimate requests,
originating from a document generated by the protected application, are guaranteed to
always contain a token when they use a session ID. The reason is that the documents
produced by the application are modified such that this token will be present.
The action to be taken when a CSRF request is detected is configurable by the site
administrator. A warning message is generated to inform the victim about the attack,
together with a (correctly tokenized) link to the application's main page. Note that
there is no need to terminate the user's current session when a CSRF attack is
detected. After following the link provided in the generated warning message, the user
can continue her work normally. An even more convenient, but less educational,
alternative would be to instantly redirect the user to the main page, without the need
for any additional interaction.
In the case when the request contains a session ID that does not exist in the token
table, we have to assume that a new session was established. The proxy generates a
new, random token and inserts the token, together with the session ID, into the token
table. In addition, the request is passed to the target application.
Reply Processing
As discussed briefly in the previous section, the task of the reply processing step is to
extend the output of a web application such that a subsequent request of the user
contains the correct token. This is achieved in a fashion similar to URL rewriting.
Assume that the proxy has to process an output page of the target application
containing the following relative hyperlink:
<a href='index.php?action=logout'> LogOut </a>
Assume further that the proxy has already determined that the client is authenticated,
and that a certain session ID is in use. In this case, it is necessary to rewrite the
hyperlink's URL such that it contains the token associated with this session ID:
<a href='index.php?action=logout &token=99'>LogOut </a>
42
When the user follows this link, the mechanism has ensured that the proper token is
transmitted.
The name of the parameter that stores the token (“token” in this example) can be
chosen arbitrarily, but must not interfere with the names of other parameters used by
the target application. The token's value (“99”) is retrieved from the token table that
the proxy maintains.
The proxy can determine a client is authenticated or not by considering the state “a
client is authenticated” as equal to “a client has an active session”. This is a safe
assumption, because CSRF attacks cannot succeed when there is no session
information that can be exploited to force the victim into performing privileged
actions (that is, actions which require previous authentication) on behalf of the
attacker.
To determine a user has an active session by using programming languages such as
PHP built-in session infrastructure that could be consulted about whether there exists
such a session. However, many applications make use of custom session management
techniques. Sometimes, session information is even stored in a back-end database. In
such cases, the target application could be instrumented with functions that enable the
proxy to issue appropriate queries about the session state. Unfortunately, this would
lead to the undesirable necessity to perform application-specific modifications.
NoForge solves the problem of determining whether a session exists in the following
way. Basically, there are two cases that have to be distinguished, depending on
whether the application sets a session cookie while processing a client's request or not.
This can be checked by searching the application's reply for an HTTP Set-Cookie
header. Of course, this approach requires our system to distinguish between session
cookies (i.e., cookies that store session information) and cookies that are set for other
purposes. While it might be possible to use heuristics to automatically identify session
cookies, require the administrator of the system to manually specify their names.
Typically, this is straightforward, as many applications make use of the built-in
session infrastructure provided by the run-time environment. For example, when PHP
43
is used, the name of the session cookie defaults to “PHPSESSID”. If a session cookie
is set in the application's reply, we assume that there exists a session, and this session
has an ID equal to the session cookie's value. If this request contains a session ID, we
conclude again that there exists a session. Such a situation arises regularly when a
client is already logged in, and her browser automatically sends the authentication
cookie to the server along with each request.
Figure 2.4 Reply processing.
After determining that there exists an active session, query the token table for an
associated token. If there is no such entry, it means that the session has been newly
created. Hence, it generates a random token and adds corresponding entry to the token
table. Finally, the reply is instrumented with the token before returning it to the client.
The following fields have to be modified:
- href attributes of a tags.
- action attributes of form tags.
- src attributes of frame and iframe tags.
- onclick attributes of button tags.
- refresh attributes of button tags.
- url attributes of refresh meta tags
However, extending the rewriting engine to take into account more fields would be
straightforward. An overview of the complete reply processing step is given in Figure
2.4.
Token Table Cleanup: The token table should be freed from stale entries regularly to
save memory and CPU time. To this end, we extended the table by a third column that
holds timestamps, which indicate the point in time when the corresponding entry was
last used. When the time that passed since this point is longer than a configurable
session life-time (that defaults to 24 minutes, in accordance with PHP's default
session life-time), the entry is removed.
44
Limitations: NoForge technique is not robust for three reasons [3]:
1. HTML dynamically created in the browser will not be re-written to include the
CSRF token. Some sites create most of their HTML on the client. For example,
Gmail, Flickr, and Digg all use JavaScript to create forms that require CSRF
protection.
2. NoForge does not discriminate between hyperlinks back to the web application and
hyperlinks to other web sites. If the web application links to another site, the remote
site will receive a copy of the user's CSRF token. For example, if phpBB adopted
NoForge, forum posters would receive a copy of the user's CSRF token if the user
clicked a link in their post. Even if NoForge discriminated between same-site and
cross-site hyperlinks, the HTTP Referer header would leak the user's CSRF token.
3. NoForge does not defend against login CSRF because it only validates the CSRF
token if the user already has a session identifier. Although this oversight is repairable,
it demonstrates the complexity of implementing secret token validation correctly.
Although each is repairable, these vulnerabilities illustrate the complexity of
implementing the secret validation technique correctly. CSRFx and CSRFGuard, as
well as many web sites, contain similar issues.
45
CHAPTER 3
PROBLEM STATEMENT
Cross-site Request Forgery (CSRF) is widely exploited web site vulnerability. It is an
attack on web applications which exploits the trust of authenticated users. By
launching a successful CSRF attack against the authenticated user, an attacker is able
to initiate arbitrary HTTP requests using the user credentials to the vulnerable web
application. A successful CSRF attack effectively bypasses the underlying
authentication mechanism and it can compromise the end user data and operation.
Very few defensive mechanisms like secret token validation, the HTTP referrer
header validation, custom HTTP header validation and origin header are available to
prevent CSRF attacks and none of these mechanisms are providing complete
protection from CSRF attacks.
This project aims at providing heuristics for preventing Cross Site Request Forgery
(CSRF) attacks. In this project, we propose the following heuristics: 1) Developing a
client-side proxy solution that detects and prevents CSRF attacks using IMG element
or other HTML elements which are used to access the static images for the webpage.
2) Developing a semi-automation mechanism to the existing SERIDE [5] (SEssion
RIding DEfender) code, which is used to prevent CSRF attacks in all PHP based web
applications.
46
CHAPTER 4
PREVENTING IMAGE BASED CSRF ATTACKS
An analysis of the widely used techniques for defending against CSRF attacks is
discussed in Chapter 3. The defensive approaches which use proxy among them are as
follows: RequestRodeo is the first client-side solution for protection against Session
Riding attacks [1]. It prevents CSRF attack by stripping the implicit authorization
information (i.e. cookie header etc.), from the outgoing cross-site HTTP requests. But
the limitation of RequestRodeo is, it cannot automatically distinguish legitimate
cross-site requests from attacks. NoForge [2] is a server-side proxy used to defend
PHP applications against CSRF attacks. In this, the proxy is located between the web
server and the protected web applications. This proxy is able to inspect and modify
client requests as well as the application’s replies (output) automatically and
transparently extend applications with the secret token validation technique.
In this chapter, we presented a client-side proxy solution that detects and prevents
CSRF attacks using IMG element or other HTML elements which are used to access
the static images for the web page. More precisely, a client-side proxy solution detects
and prevents all kinds of IMG (image) based CSRF attacks in a way that is
transparent to users as well as to the web application itself. OWASP’s open source
Webscarab proxy plug-in [11] in the CSRFTester tool is used as a client-side proxy.
The chapter is organized as follows: section 1 gives the image retrieval details.
Section 2 illustrates image based CSRF attack with an example. Sections 3, 4, 5 and 6
explain the solution to prevent image based CSRF attack, its implementation details,
experimental results and the future work respectively.
4.1 Image Retrieval
HTML has the ability to include images with text in the following ways: as an inline
image, as a background image, or can be linked to a different image source via
hyperlink. When a browser requests a webpage, it can’t know that the page has an
image. The browser realizes this only when it parses the HTML within the response.
47
At this point the browser sends a separate HTTP GET request to the web server to
retrieve the image. The web server replies with the requested image data [32].
The HTML IMG element is widely used for embedding images into the HTML
document and is supported by all major web browsers. The basic attributes of IMG
element are: src, alt, align, border, dynsrc(IE), height, hspace, ismap,
lowsrc(Netscape), name(Netscape), usemap, vspace and width [32, 33].
The IMG element Attribute Specifications are
• SRC = URI (location of image)
• ALT = Text (alternate text)
• LONGDESC = URI (link to long description)
• WIDTH = Length (image width)
• HEIGHT = Length (image height)
• USEMAP = URI (client-side image map)
• ISMAP (server-side image map)
• ALIGN = top | middle | bottom | left | right (image alignment)
• BORDER = Pixels (link border width)
• HSPACE = Pixels (horizontal gutter)
• VSPACE = Pixels (vertical gutter)
• NAME = CDATA (name for client-side scripting)
• common attributes
The src attribute of IMG element is used to provide the absolute or relative URI
(Uniform Resource Identifier) of the image to be displayed. This embeds an image in
the HTML document at the location of the element’s definition. The image can be any
format, though browsers generally only support GIF, JPEG, and PNG images.
The alt attribute is used to give replacement text, which will be displayed when the
particular image is not loaded by the web browsers (user agents). Browsers display
the alternate text when they cannot support images, they cannot support a certain
image type or when they are configured not to display images. The value for the alt
attribute is a text string of up to 1024 characters, enclosed in quotation marks if you
include spaces or other punctuation. The alternative text may contain entity references
48
to special characters, but it may not contain any other sort of markup; in particular, no
style tags are allowed.
The lowsrc attribute is used to specify the URI of the low resolution equivalent of the
image specified by the src attribute. It is useful for the users with slow internet
connections because it speeds up the document rendering. The lowsrc attribute’s
value, like src, is the URL of an image file that the browser loads and displays when it
first encounters the IMG element. Then, when the document has been completely
loaded and can be read by the user, Netscape goes back and retrieves the image
specified by the src attribute. The lowsrc attribute is for Netscape only. Other
browsers ignore it and only load the image specified by the src attribute. Otherwise
nothing will appear except the missing image icon.
The dynsrc attribute loads a movie file instead of a still picture file. Internet Explorer
treats dynsrc movies similar to inline images: in line with current body content and
according to the dimension of the video frame. And, like common images, the dynsrc
referenced movie file gets displayed immediately after download from the server.
Browsers (except Internet Explorer) that recognize dynsrc will ignore the link
specified in the src attribute.
The longdesc attribute gives the link to a long description of the image. This
description should supplement the short description provided using the alt attribute.
The following code illustrates the usage of these attributes of IMG element to retrieve
images:
<IMG src="http://example.com/logo1.gif” alt=”nitklogo” />
<IMG src=”logo1.gif” lowsrc="logo1_lowres.gif" />
<IMG src="logo1.gif" alt=”logo” longdesc=”logo.html”/>
<IMG src="sample.gif" dynsrc="test.avi">
When the image has an associated imagemap, this attribute should provide
information about the image map’s contents. This is particularly important for server-
side image maps. Since an img element may be within the contents of an A (anchor)
element, the user agent’s mechanism in the user interface for accessing the longdesc
49
resource of the former must be different than the mechanism for accessing the href
resource of the latter.
The ismap and usemap attributes for the IMG element tells the browser that the image
is a special mouse-selectable visual map of one or more hyperlinks, commonly known
as an image map. The ismap attribute is used to indicate the user’s mouse actions over
the image and it is processed using a server-side image map. It is only possible to
define a server-side image map for the IMG and INPUT elements. In the case of IMG,
the IMG must be inside an A (anchor) element and the boolean attribute ismap must
be set. In the case of INPUT, the INPUT must be of type "image". When the user
clicks on an area of the image using the mouse, the coordinates are sent back to the
server in the form of a query string in the URI [34]. Screen coordinates are expressed
as screen pixel values relative to the image.
An example for ismap is:
<A HREF="/imagemap/map1"> <img src="pics/map1.gif" ismap> </A>
The browser automatically sends the x,y position of the mouse (relative to the upper-
left corner of the image) to the server when the user clicks somewhere on the ismap
image. Special server software (the /imagemap/map1 program in the example) may
then use those coordinates to determine a response.
The usemap attribute provides a client-side image map mechanism that effectively
eliminates server-side processing of the mouse coordinates and its network delays and
problems. Using special map and area elements, HTML authors provide a map of
coordinates for the hyperlink-sensitive regions in the usemap image along with related
hyperlink URLs. The value of the usemap attribute is a URL that points to that special
map section. The browser on the user's computer translates the coordinates of a click
of the mouse on the image into some action, including loading and displaying another
document.
For example, the following source specially encodes the 100-pixel wide by 100-pixel
tall map1.gif image into four segments, each of which, if clicked by the user, links to
a different document. Also notice that we've included, validly, the ismap image map
processing capability in the example IMG element so that users of other, usemap-
50
incapable browsers have access to the alternative, server-side mechanism to process
the image map:
<a href="/imagemap/map1"><img src="pics/map1.gif" ismap usemap="#map1">
</a>
...
<map name="map1">
<area coords="0,0,49,49" href="link1.html">
<area coords="50,0,99,49" href="link2.html">
<area coords="0,50,49,99" href="link3.html">
<area coords="50,50,99,99" href="link4.html">
</map>
Geographical maps make excellent ismap and usemap examples: browsing a
nationwide company's pages, for instance, the user might click on their home town on
a map to get the addresses and phone numbers for nearby retail outlets. The advantage
of the usemap client-side image map processing is that it does not require a server or
special server software and so, unlike the ismap mechanism, can be used in non-web
(networkless) environments, such as local files or CD-ROM.
The images can also be displayed on a webpage by specifying the URI of the image in
the src attribute of INPUT element, data attribute of OBJECT element, or the
background attribute of the BODY, TABLE or TD elements. If the type attribute
value is image in the INPUT element then it creates an image, which can be used as a
button. The src attribute must be included to specify the URI of the image. The alt
attribute should be used to give replacement text for those not loading images. Images
can be accessed using the OBJECT element, by setting the type attribute value to
image and URI of the image to data attribute.
The following code illustrates the above explained elements:
<INPUT type="image" src="submit.gif" alt=”submit”/>
<OBJECT type="image/jpg" data="logo3.gif"></OBJECT>
<BODY background= "background1.gif" >
<TABLE background=”background2.gif” >
<TD background= “background3.gif” >
51
In Cascading Style Sheets, background: url(“URI”); and background-image:
url(“URI”); attributes are used to specify the image as shown below:
body
{
background: url ("background2.gif");
background-image: url ("background3.gif");
}
In JavaScript, Image() object is used to specify the target image location. An example
code snippet is shown below:
<script>
var imageobj = new Image();
imageobj.src=”logo.gif”;
</script>
An attacker can include a CSRF attack code or redirect the victim to a malicious
webpage using suitable values for the src attributes. CSRF attack is not possible with
alt, name, height, width, usemap and ismap attribute values of IMG element. The
attacker could also create a CSRF attack using CSS background and background-
image attributes and JavaScript image objects.
Dynamic Image requests: Dynamic images are images that change depending on
condition. To include custom, up-to-date images in a web page, user has to send a
dynamic image request with the desired parameters. The request is dynamic in the
sense that every time a web page is displayed with an up-to-date image with the given
parameters. The dynamic image’s URL could be something like:
<img src="http://example.com/dynaimage.php/img=logo.gif&isize=100&dynimg=y"
width="200" height="200" border="0" alt="Nitk logo" />
The URL is actually a PHP file producing a dynamic image in this case. These
dynamic images are useful if you want to change the image produced at any point.
4.2 Image based CSRF attacks
The CSRF attacks exploit the browsers’ feature of sending the authentication
information along with every POST/GET HTTP request to the target application. An
52
attacker identifies a URL on a website like a banking application that performs some
functions like purchase, money transfer or any transaction or update account. An
attacker posts the particular URL onto a web page on which they have control. When
the victim visits the webpage the URL is triggered (via an Image Request). The
browser sends the authenticated information for the particular website along with the
request [35].
Image based CSRF attack works by including HTML image based elements,
attributes or image objects in a page that accesses a site to which the user is known (or
is supposed) to have authenticated. For example [8], a banking site that provides a
HTML form to place online credit transfers. This form uses the GET method and has
the action URL http://bank.com/transfer.php. The form is only accessible by properly
authenticated users. One user, Alice, is logged into bank.com website and at the
same time browsing a chat forum ABC, where another user, Mary, has posted a
message. Suppose that Mary has crafted an HTML image element that references a
feature/webpage on Alice's bank's website (rather than an image file).e.g.
<IMG src=”http://bank.com/transfer.php?account=Alice &amount=100000&
for=Mary” width=”0” height=”0” />
Figure 4.1 CSRF attack using IMG element.
53
We assume that the bank website keeps Alice authentication information in a cookie.
If the cookie hasn't expired, and at the same time Alice views the crafted message sent
by Mary, then the Alice’s browser will attempt to load the image, and it will submit
the transfer request with Alice credentials to bank.com server without requiring any
further interaction from the Alice. Thus authorizing the malicious transaction by the
bank’s server. Figure 4.1 shows the process of CSRF attack in the above example.
The following is another simple example to illustrate real-world Image based CSRF
attack request to logout from the authenticated Gmail session:
<IMG src="http://mail.google.com/mail?logout&hl=en-GB" width=”0” height=”0” />
The attacker places the above image based CSRF attack request in some vulnerable
website. When an authenticated Gmail user visits the vulnerable site, the browser
tends to retrieve the image specified in the IMG src attribute, thus sending a logout
request to Gmail, with the users’ credentials. This results in successful logout due to
CSRF. Due to the lack of anti-CSRF mechanism, many websites are vulnerable to this
logout attack. It is not a severe attack but it clearly explains how Image based CSRF
attack can be used against websites to perform malicious activities and cause
inconvenience to the users.
While using the IMG element is a common method to create the CSRF attack, it is by
no means the only HTML element that can be used to perform this attack. The other
HTML elements and attribute values mentioned in section 4.1 can be used to create a
CSRF attack. The script and iframe elements are also used to perform CSRF attack.
These elements could also have URLs embedded within them that create the
automatic HTTP request with a malicious action. The attacker could also create a
CSRF attack using JavaScript Image objects.
GET requests are especially vulnerable to CSRF attack, but POST requests are not
immune. An attacker could write their own website and use JavaScript to auto submit
their form to a target location on a victim's website. While using a POST request to
perform this attack makes it much more difficult to implement than performing a GET
request, the attack is still possible. The CSRF attack takes advantage of the fact that
54
many users tend to forget to logout of the web applications they have used. This does
not provide the web applications a chance to clear their session IDs or other types of
session information from the cookie, allowing the CSRF attack to be successful even
when the user is not actively browsing vulnerable websites.
4.3 Prevention of Image based CSRF attacks
This section presents a client-side solution to enable security conscious users to
protect themselves against Image based CSRF attacks.
Concept: The CSRF attacks are possible due to the fact that the browser automatically
sends the GET requests for all kinds of HTML image elements while rendering a
webpage. By using these image elements, it is very simple to exploit any vulnerable
website. This is because, the web browsers do not validate the URL specified by the
IMG element attribute before sending a request for that image.
Identification of suspicious image elements: Most of the websites use the static image
URL’s to obtain the images in their web pages. The widely recognized image formats
include GIF, JPEG, and PNG. The other formats supported by popular browsers are
jpg, bmp, xbm. So if the website uses a static image URLs then the URLs must end
with gif, jpeg, jpg, png, bmp or xbm extension. We can successfully mitigate the
CSRF attacks using static images by checking the extensions and validating the URL
specified in all the types of image elements before the browser renders the webpage.
The proposed solution works as a local proxy on the user’s computer and disables the
automatic dispatching of GET requests for all image elements. The proxy identifies
all the image elements in the response page and validates the URI for each image
element in the webpage source code. If the proxy detects any invalid URL (i.e. URL
without valid image extension), it disables that image element. If there is a dynamic
image in the webpage, an alert is displayed to the user and based on the user response
the image request is processed or blocked.
55
4.3.1 A Proxy-Based Solution
Figure 4.2 Client-Side Proxy Solution.
The implemented solution is in the form of a proxy because this approach enables
CSRF protection for all the web browsers. Figure 4.2 shows the general setup of the
web browser, the client side proxy and the web server.
Identification of suspicious requests: The proxy resides between the client’s web
browser and the web application’s server. Every HTTP request and response is routed
through the proxy. Due to the fact that the browser and the proxy are separate entities,
the proxy is unable to identify how an HTTP request was initiated for the images. To
decide if an image element is legitimate or suspicious of CSRF, we introduce the
following classification criteria: Once the response is received from the web server for
each request, the client-side proxy checks for image extensions in the static image
URLs. If any invalid URL is found then the proxy blocks that image element by
enclosing it within the CDATA element and it forwards the response to the browser.
If the response contains valid image URLs then proxy forwards the response content
intact to the browser without any modifications.
4.3.2 Limitations
Our current proxy solution successfully prevents the CSRF attack using all kinds of
static image URLs except the JavaScript Image objects. In this solution, we are
blocking the dynamic image URLs in the response page because these do not have the
image extensions (.jpg etc.) like in static image URLs. In this approach, there is a
56
chance of false positives when the actual image URLs does not have the valid image
extensions (i.e. jpg etc.). Usage of dynamic URLs in the webpage is very less as
compared to static image URLs and these are used mainly for advertisements. So
blocking advertisements is advantageous to the users, but some users may want to see
the advertisement or some websites restrict the user to login to the site only after
viewing the advertisement.
The IMG attribute longdesc can specify the attacker’s controlled site where attacker
posted a malicious code. So the attacker can redirect the user and can perform the
attack. Our solution is not immune to this kind of attack. We can provide an option to
the user to block this attribute as a partial solution.
4.4 Implementation Details
OWASP’s CSRFTester tool and webscarab proxy plug-in is used to test the
implementation. Basically the CSRF Tester tool is used to test for CSRF
vulnerabilities [11]. The proxy plug-in in CSRFTester sets up a HTTP proxy and
listens by default on localhost port 8008. This plug-in accepts both HTTP and HTTPS
requests. Additional details of CSRFTester tool is explained in Appendix II.
Figure 4.3 CSRFTester tool
Figure 4.3 shows the sample screenshot of CSRFTester tool. Additional details of this
tool are explained in the Appendix-II.
57
The image based CSRF prevention code is implemented in Java and is integrated with
the webscarab proxy plug-in (org.owasp.webscarab.plugin.proxy) in the CSRFTester.
Java regular expression functions are used to check for the valid extensions of static
image URLs.
The sample procedure for checking IMG element URL’s in the response is as follows:
1. Obtain all the image elements by compiling the Regular expression pattern
"<\\s*img[<^>]+>"
2. Obtain all the URLs present in the image elements by compiling the pattern
"src\\s*=\\s*('|\"){0,1}\\s*([^\\s\"\'\\(\\;\\#\\&\\<\\?][A-Za-z0-9\\_\\.\\/\\:\\-\\%\\~]*)
\\s*('|\"){0,1}"
3. Check the extension of the URL by compiling the pattern
".*\\.(gif|png|jpg|jpeg|bmp|xbm)$".
If the URL matches with the extension then it is valid. Otherwise it is treated as
invalid and the image element is included inside the CDATA section. We can delete
the malicious image elements if we don’t want to comment it with CDATA.
The above mentioned procedure is implemented in java [36] and the code detects the
malicious IMG URLs and prevents CSRF attacks using IMG elements. It prevents the
CSRF attack by including that entire malicious IMG element inside the CDATA
element. CDATA sections are used to escape blocks of text containing characters that
would otherwise be regarded as markup. The only delimiter that is recognized in a
CDATA section is the "]]>" string that ends the CDATA section. Putting
<![CDATA[...]]> round a section essentially says "do not parse this section -
everything in it should be interpreted as characters". So, in the example:
<![CDATA[<img src=”http://placement.nitk.ac.in/student/logout/logout.php” /> ]]>
is exactly same as:
<img src=”http://placement.nitk.ac.in/student/logout/logout.php” />
The XML parser sees it as a string, not a tag so same string gets displayed in the
browser. The primary purpose of CDATA is to include material such as XML
fragments, without needing to escape all the delimiters [30]. The same procedure is
followed for other image elements mentioned in section 4.1 except JavaScript Image
objects.
58
4.5 Experimental Results
To test our implementation, initially we gathered different types of IMG elements
(including XSS attacks using IMG tag) with all attributes and their values, INPUT,
OBJECT elements, background attribute and CSS background: url(), background-
image: url() attribute values. Our implementation successfully disabled these image
based CSRF attacks from executing. The following are the websites tested for finding
image based CSRF attacks. The experimental results from table 4.1 show that our
current implementation successfully blocked all the static image elements containing
CSRF attack code and also the dynamic image elements present in the response. The
CSRF attacks are much harder to test because the attacker can include the malicious
IMG tag whenever required and delete them once the attack is successful on the
required victim(s).
Website Total
Images
Blocked
Images Reason for blocking the Images
Localhost (all
images are
malicious)
100 100 The image source contains malicious code
(including XSS scripts, logout URLs etc.)
Localhost(100
Malicious &50
normal Images)
150 100 The URL of images contains malicious code
(including XSS scripts, logout URLs etc.)
www.cricinfo.com 93 5 The site uses dynamic URLs inside the IMG
element for displaying advertisements.
timesofindia.indiat
imes.com 45 37
The site uses CMS system to generate
dynamic URLs
cmt.nitk.ac.in
(NITK forum) 9 3
The site contains Gmail , cmt site Logout
and message URLs [posted by the author
(login required)]
www.nasa.gov 163 0 All are using valid image URLs
dsc.discovery.com 65 11 Blocked the dynamic image URLs
www.nationalgeog
raphic.com 90 19 Dynamic URLs used for Advertisements
www.nytimes.com 54 2 Dynamic URLs used for Advertisements
Table 4.1 Tested Applications
59
Figure 4.4 shows the output of our tool, when it was tested on cmt.nitk.ac.in chat
forum. This website is vulnerable to image based CSRF attacks since it is allowing
the users to post (malicious) HTML content in the forum.
Figure 4.4 Test results on cmt.nitk.ac.in chat forum
4.6 Future Work
Validating JavaScript image objects is yet to be implemented. The existing code can
be extended to include this functionality to protect against JavaScript image object
based CSRF attacks. To execute and test our implementation, we used CSRFTester
tool user interface and webscarab proxy plug-in as the proxy. Providing more number
of options to the user such as allow or block the dynamic images, view the entire
images list in the webpage etc and a separate GUI need to be implemented to make it
as a separate tool. This solution can also be made browser specific by creating an
add-on to the browsers like Firefox.
60
CHAPTER 5
SA-SERIDE: SEMI-AUTOMATED SERIDE TOOL
Cross Site Request Forgery is also known as “Session Riding”. There are few
defensive mechanisms available to prevent CSRF attack and there is no 100% way to
prevent this attack due to the concept that the attack fully stands on the users’
credentials. In order to prevent CSRF, an additional parameter must be added to a
request, either on the URL line parameters or in POST parameters. This is
implemented by adding the parameter to a form as a hidden field or to the “action”
(location where the form submits). This parameter must not be something that the
attacker can determine so he or she cannot construct a link or script to execute a
CSRF. This is possible by using secret token validation mechanism.
Secret token validation mechanism is one of the most efficient mechanisms to prevent
CSRF attacks. SERIDE (SEssion RIding DEfender) [5] is an open source PHP library
which uses secret token validation mechanism to prevent CSRF attacks successfully
in all PHP based web applications. This code has been developed by Nexus and is
available at www.playhack.net. This chapter discusses all the details of SERIDE code
and SA-SERIDE tool, a semi-automated tool and an improved version to the existing
SERIDE code. These are providing a server side solution to prevent the CSRF attacks.
This chapter is organized as follows: Section 1 presents a description about SERIDE.
Section 2 gives the drawbacks in the SERIDE code and its improvements. Sections 3,
4 and 5 explain the Semi-Automated SERIDE tool, its implementation details and
experimental results respectively. Section 6 presents the future work of SA-SERIDE
tool.
5.1 SERIDE: SEssion RIding DEfender
SERIDE is a PHP library for countering the Session Riding/CSRF attack attempts. It
is an open source code developed by Nexus and the current version (i.e. seride_v0.2)
is available at www.playhack.net [5]. To prevent CSRF attacks, SERIDE appends
61
one-time token values for both forms and links (using anchor tags) data upon POST or
GET request by the user.
5.1.1 SERIDE working procedure
To protect from CSRF attacks, the basic procedure followed by the SERIDE code
upon a form data request by the client is shown in Figure 5.1 and is explained as
follows:
1. Website administrator assigns a SERIDE token generation function as a hidden
variable value to the webpage form.
2. Whenever client requests the form, the one-time token will be generated at the
server and sent to the client along with the requested form.
Figure 5.1 SERIDE token generation and validation for a form
3. Client submits the form back to the server along with the obtained token (in the
form of POST or GET request).
4. The SERIDE code checks the validity of the received token from the client form.
If the token matches with the generated token then it is legitimate and will continue
the next page generation and sent to the client. If the token doesn’t matches then there
may be a CSRF attack and it will abort the operation and report the error back to the
client.
To protect from CSRF attacks, the basic procedure followed by the SERIDE code for
the links (using anchor tags) in the webpage requested by the client is shown in Figure
5.2 and is explained as follows:
62
1. Website administrator appends a SERIDE token generation function to all the links
in a webpage which belong the same site (these links are treated as legitimate).
2. Whenever client requests the webpage, the one-time tokens will be generated at the
server and sent to the client along with the legitimate links.
3. If the Client clicks on any legitimate link or sends a GET request to the server using
the legitimate link, then the server will receive the token with the client request.
4. The SERIDE code checks the validity of the received token from the client link
request. If the token matches with the generated token then it is legitimate and will
continue the next page generation and sent to the client. If the token doesn’t matches
then there may be a CSRF attack and it will abort the operation and report the error
back to the client.
Figure 5.2 SERIDE token generation and validation for a link
The implementation details of the SERIDE code is explained in the following section.
5.1.2 Implementation Details of SERIDE
In order to make the web forms and links safe from Session Riding or CSRF, SERIDE
uses one-time tokens that cannot be guessed or retrieved in any way and after having
accomplished their task would have been destroyed. The implementation details of
token generation and validation functions are explained as follows [28].
Token value generation: the following gen_hash() function is used to generate unique
token value using MD5 (or SHA1).
<?php
function gen_hash(){
63
$hash = md5(uniqid(rand(), true)); // Generate the md5 hash of a randomized uniq id
$n = rand(1, 24); // Select a random number between 1 and 24 (32-8)
$token = substr($hash, $n, 8); /* Generate the token retrieving a part of the hash
starting from the random N number with 8 of length*/
return $token;
} ?>
The uniqid() PHP function allows the web developer to get a unique ID from the
current time in microseconds, which is quite good in order to retrieve a value that
won't be repeated again. The MD5 hashing of that ID is retrieved, and then 8
characters from that hashing starting from a random number <=24 (strlen($hash)-8) is
selected. The returned $token variable will retrieve an 8 characters long randomized
token.
Session Token Generation: the following create_stoken() function is used for Session
Token generation which will be used later for the last check:
<?php
function create_stoken() {
$token = gen_token(); // Call the function to generate the token
destroy_stoken($token); // Destroy any eventually Session Token variable
session_register($token); // Create the Session Token variable
$_SESSION[$token] = $time();
return $token;
}
?>
With this function we call the create_stoken() function and use the returned token to
copy this value into a new $_SESSION variable.
Embedding token value in the Form: the seride_form() function will start the whole
mechanism and generates the hidden input for the form:
<?php
function seride_form() {
$token = create_stoken();// Call the function to generate the Session Token variable
// Generate the form input code
echo "<input type=hidden name=".TOKEN_NAME."value=".$token.">\n";
64
}
?>
This function just call the create_stoken() function and create the HTML code for the
hidden input that will be included in the web form.
Appending token value to a link: The seride_link() function is used to protect the link
like http://yourhost.com/logout from being potentially hijacked.
And the function is:
function seride_link($link) {
$token = create_stoken(); // Call the function to generate the Session Token Variable
$link .= "&" . TOKEN_NAME . "=" . $token . ""; /* Modify the given link and include
the token.*/
return $link;
}
if you want to protect a standard link you have to modify your HTML link using the
'seride_link()' function as presented:
<a href="<?=seride_link("http://www.yourhost.com/page1.php");?>">your link</a>
seride_check() function (or) token validation function: the seride_check() function
checks and compares the Session Token with the received hidden input token in a
form or a token in a link.
<?php
function seride_check() {
global $token_timeout, $abort;
if(isset($_REQUEST[TOKEN_NAME])) // Check if the request has been sent
{
if(is_session($_REQUEST[TOKEN_NAME])) // Check if the Session token exists
{
if($_SESSION[$_REQUEST[TOKEN_NAME]] != '')
{ // Calculate the token age
$token_age = time() - $_SESSION[$_REQUEST[TOKEN_NAME]];
$token_timeout = $token_timeout*60; // Calculate the timeout limit in seconds
if($token_age <= $token_timeout) // Check if the token did not timeout
{
destroy_stoken($_REQUEST[TOKEN_NAME]);
}
else{ // Else is a malitious request
seride_error(4);
destroy_stoken($_REQUEST[TOKEN_NAME]);
65
if($abort == "Yes") { // Check if the page creation should be aborted
exit();
}
} // Else is a malitious request
}
else {
seride_error(3);
destroy_stoken($_REQUEST[TOKEN_NAME]);
// Check if the page creation should be aborted
if($abort == "Yes") {
exit();
}
} // Else is a malitious request
}
else {
seride_error(2);
destroy_stoken($_REQUEST[TOKEN_NAME]); // Check if the page creation should be aborted
if($abort == "Yes") {
exit();
}
} // Else is a malitious request
} else {
seride_error(1);
destroy_stoken($_REQUEST[TOKEN_NAME]); // Check if the page creation should be aborted
if($abort == "Yes") {
exit();
}
}
}
This function check the existence of the $_SESSION[TOKEN_NAME] and of
$_REQUEST[TOKEN_NAME] (the $_REQUEST method is used in order to accept
both GET and POST methods from the form) and check if their values are the same: if
they are and the age of the token is less than specified maximum time limit, then the
submitted form is authorized. The important point of this function is that at every
concluding step the tokens get destroyed using destroy_stoken() function and will be
recreated only at next web form page call. The use of these functions is really simple
we just need to just add some additional PHP instructions.
66
5.1.3 Installation and usage of SERIDE
In order to properly install and use the SERIDE library first of all open the core file
(i.e. seride.php) with a text editor and configure the available options in order to
personalize the protection. After that upload the just modified file to the remote path
you want Seride to be saved. In order to make Seride be active and protect some
pages you'll need to edit your PHP source code files as following.
Remember to always include the 'seride.php' file in every page you want it to be
active using the following instruction:
<?php
include("seride.php"); // Insert this instruction at the top of the page
?>
In the case you have to protect a web form just use the following instruction:
<!-- Insert this instruction before the </form> tag -->
<?=seride_form();?>
Instead if you want to protect a standard link you have to modify your HTML link
using the 'seride_link()' function as presented:
<a href="<?=seride_link("http://www.yourhost.com/display.php");?>">your link</a>
In the target page of the form or of the link you just need to insert in the code the
following instruction (remember to include the 'seride.php' file at the top of every
page):
<?php seride_check(); ?>
Note that in order to properly work you need to place the 'seride_check()' function
before any code that would resolve the sent request, it would be better if you place at
the top of the page right after the 'include("seride.php");' code.
You have now SERIDE library up and running and protecting your website from any
hijacking attack attempts.
Example to generate and validate the seride token in the form:
This is the web form:
<!-- form.php -->
<?php
session_start();
include("seride.php");
67
?>
<FORM method="POST" action="resolve.php">
<input type="text" name="name">
<input type="text" name="surname">
<!-- Call the function to generate the hidden input -->
<?=seride_form(); ?>
<input type="submit" name="submit" value="Submit">
</FORM>
And this is the resolving script:
<!-- resolve.php -->
<?php
session_start();
include("seride.php");
seride_check();// Call the function to make the check
// Your code
...
?>
This is really simple to implement such a check and it should protect the users from
being hijacked by attackers and avoid the data gets compromised.
5.2 Required changes to improve the SERIDE code
The following changes are required to improve the existing SERIDE code (the current
version is: seride_v0.2).
5.2.1 Randomized selection of hashing algorithms (MD5, SHA1) for generating a
token
The ‘seride.php’ code provides an option to manually select either sha1 or md5 for
generating a token. Manual selection of hashing algorithm is not so efficient. So we
can choose either SHA1 or MD5 dynamically by generating a random number, so that
we can prevent brute force attempts to generate the same token by an attacker.
Randomized selection of hashing algorithm provides more security by obfuscation.
$selecthash=rand(1,100);
if($selecthash % 2 == 0)
{
68
$hashing_algorithm="md5";
}
else
{
$hashing_algorithm="sha1";
}
5.2.2 Improvement to the seride_link() function
If we call the $link= seride_link("http://www. yourhost.com/page1.php"); function
then the resulting URL is:
$link= http://www.yourhost.com/page1.php&seride_token=12345678; which is not a
valid URL and it is incorrect. But the required URL is:
$link= http://www.yourhost.com/page1.php?seride_token=12345678;
Adding &seride_token=value works well only if the URL (Uniform Resource
Locator) is having query string parameters. Many times the URL may consist of only
domain part. If the URL or link does not have query string part (e.g.
http://www.nitk.ac.in), then adding token to the URL just by appending with
&token=value will not work and it will report error message like page or object not
found. We should append the ‘?’(Question mark) before appending 'token=value' to
the URL. Note that in this case we should not append ‘&token=value’ (along with &)
to the URL after appending ‘?’(i.e. http://www.nitk.ac.in?&token=value is not
correct). Still some changes are required to append 'token=value' to all kinds of
URL's.
The improved code for seride_link() function is:
function seride_link($link) {
$token = create_stoken(); // Call the function to generate the Session Token Variable
$pattern="\?";
if(ereg($pattern,$link)){
// Modify the given link and include the token along with &.
$link .= "&" . TOKEN_NAME . "=" . $token . "";
}else{
// Modify the given link and include the token along with ?
$link .= "?" . TOKEN_NAME . "=" . $token . "";
}
69
return $link;
}
Note: Even this function will not work for some URL’s. The example URL is:
http://www.nitk.ac.in/ (i.e.URL ends with /).
5.2.3 Improvements to the SERIDE (seride_v0.2) code
SERIDE code can be improved by adding some more validation conditions to the
existing functions.
1) Check the validity of the URL (as per RFC 1738,) before appending token to the
URL using seride_link() function.
2) Append the “&tokenname=value” (or “tokenname=value” or ?tokenname=value”)
based on the format (or type) of valid URL.
3) “tokenname=value” can’t be appended to the URL’s which are referring the third-
party sites. (This can be validated by obtaining domain part from the URL, if any). To
do this, obtain the individual parts of URL (protocol part and domain part), and
compare whether the domain in the URL belongs to the same site or not. If it belongs
to the same site then append the token, otherwise return the link without appending
the token value.
In other case, if the URL does not have these (protocol and domain) fields (relative
URL which belongs to the same site,) then we can append the token to the URL. If the
URL (without protocol and domain parts) does not belongs to the same site, adding
“token=value” to that URL will not reveal the token information to any third-parties
(or attackers).
4) Automate the mechanism of inserting seride_form(), seride_link() and
seride_check() functions in each webpage source code.
5) Develop a GUI which will do all these tasks and provide a nice interface to an
administrator or the user.
5.3 Semi-Automated SERIDE Tool (SA-SERIDE)
SA-SERIDE tool is an open source tool and developed to automate the process of
adding token generation and token check functions to all the valid forms and links
70
present in the PHP applications. Along with this functionality, the changes required to
improve the existing SERIDE code (seride_v0.2) discussed in section 5.2 is also
implemented. Performing these tasks (i.e. adding token functions to forms and links)
is not fully automated. That’s why we named this tool as semi-automated SERIDE
(SA-SERIDE) tool.
5.3.1 SA-SERIDE working procedure
The working procedure of SA-SERIDE tool is as follows:
The diagrammatic representation of the SA-SERIDE tool working procedure is shown
in Figure 5.3.
1) SA-SERIDE tool reads a PHP file (with valid path) as input, where user wants to
add seride token functions for all the valid forms and links present in that file. User
has to give the domain name as input to this tool along the file name.
Figure 5.3 SA-SERIDE tool for both form and link validation and token handling
71
2) The SA-SERIDE tool read the given filename and opens the file in read mode if the
file exists. It creates a new file and opens it in write mode. The tool write the
following code <?php include(“ seride.php”); ?> to the new file.
3) The SA-SERIDE tool checks the total number of form beginning (i.e. <form>) and
form ending (i.e. </form>) tags. If these don’t match then there is chance of
misplacing token generation function in another form. So to avoid this problem, this
tool generates an error alert to the user and stops the process of adding token
generation functions to the code.
4) The SA-SERIDE tool reads the given PHP code line by line and checks for the
form beginning tag and anchor (<A>) tag. If there is any form tag or anchor tag, then
the SA-SERIDE tool validates the domain name of the URL present in these tags. If
the domain name of the URL matches with the user specified domain name then it
will append corresponding token generation function to the URL.
5) If the SA-SERIDE tool finds a form tag and a valid URL in the form action
attribute (i.e. valid form), then it will append a hidden INPUT element to that form.
The SA-SERIDE tool reads the code from the opened file and writes the same until it
found the form end tag. Once the tool find the form end tag, it will append the hidden
INPUT element with the value create_stoken(), a function in the SERIDE code used
to generate a new random token value to the form end tag and write the resulting code
to the new file. The tool assigned a seridetoken as name to the hidden INPUT
element.
6) If the SA-SERIDE tool finds a anchor tag and a valid URL in the href attribute of
anchor tag (i.e. valid Anchor), then it will replace the URL with the seride_link(), a
function in the SERIDE code and pass this URL as argument to the seride_link()
function. Then the tool writes the resulting anchor tag code to the new file.
7) The tool repeats the steps 4, 5 and 6 until it reaches the end of the file.
5.3.2 Implementation details of SA-SERIDE Tool
The main aim of SA-SERIDE tool is to find all the valid forms and anchor tags in the
given PHP web page source code in an automated way and make the web forms and
links safe from Session Riding by using one-time token mechanism. These generated
tokens for forms or anchor tags cannot be guessed or retrieved in any way and after
72
having accomplished their task would have been destroyed. The implementation
details of token generation and validation functions in SA-SERIDE tool are same as
in SERIDE code. In this tool, we made minor modifications to the token functions to
improve their functionality (as explained in section 5.2) and provided user interface to
submit a file to SA-SERIDE tool. So in this section, we present the implementation
details of semi-automated way of SA-SERIDE to find valid form and anchor tags.
Semi-automated way of finding anchor and form tags and appending token functions :
Step 1: After obtaining the source code of a PHP file, the SA-SERIDE tool compares
the total number of <form> tags with </form> tags. If both are equal then it proceed
further. Otherwise it stops the process and reports the error to the user. The PHP code
for doing this task is:
$totalformtags=preg_match_all('/<\s*form[^>]+>/i',$sourcecode,$listofformtags);
$totalformendtags=preg_match_all("@<\s*/form\s*>@i",$sourcecode,$formendtags);
if($totalformtags != $totalformendtags) {
echo “<br />Some mismatch occurred in putting <form> and </form> tags. “;
echo “please rectify it. Thank you<br />";
exit;
}
Step 2: SA-SERIDE tool opens a new file and write the include(seride.php) code.
$includefilecode="<?php"."\n"."include(\"./seride.php\");"."\n"."?>"."\n";
fwrite($fpw,$includefilecode);
Step 3: the tool first check the presence of anchor tag in the source code of input file.
$anchortagpresent=preg_match("/<\s*a[^>]+>/i",$line,$achorbegin);
if there is an anchor tag, and consists of href attribute then this tool check the URL of
the domain, if the domain matches with the user specified web site domain, then this
tool will replace the href attribute value with seride_link(), a function used for
appending token value to the URL and pass the URL value as argument to this
function.
$replacehref=”seride_link($echoexist[1]$hrefattribute[2]$echoexist[1])”;
$line=str_replace($replacesrc,$replacehref,$line);
73
If the domain value of URL is different from user specified web site domain, then the
tool will write the same code into the new file and read the next line of input source
code.
Step 4: the tool check the presence of form tag in the source code of input file, if there
is form tag then it will check the domain of the form action attribute value (i.e. URL).
$formactionpattern='/action\s*=\s*(\'|"){0,1}([^\s\"\'\(\;\#\&\<][A-Za-z0-9\_\.\/\:\-
\%]*)(\'|"){0,1}/im';
Read the input file until it finds the form end tag. If the domain matches then replace
the form end tag with the following line of code.
$replaceformend="<input type=hidden name=seridetoken value=create_stoken();/>
</form>";
The tool repeats the above steps until it reaches the end of input file.
5.3.3 Installation of SA-SERIDE Tool
In order to properly install and use the SA-SERIDE tool first of all open the cores
files (i.e. seride.php, readurl.php) with a text editor and configure the available
options in order to personalize the protection. To execute and use this tool either
localhost web server (i.e. XAMPP [37] or WAMP [38]) or software to run the PHP
files is required. After installing the required software, follow the steps mentioned in
section 5.1.3 and section 5.3.1.
5.3.4 Experimental results
This section presents the practical implementation details and usage of the SA-
SERIDE tool and SERIDE code.
5.3.4.1 Sample application
Consider a sample application of buying shares. The form and its source code are as
shown below. This application illustrates the possibility of CSRF attack if the
application is not using the SERIDE token functions internally and the prevention of
this attack when the application uses the SERIDE token functions in its code.
Buy shares application (without SERIDE protection):
Buyshares.php
74
<?php //This is an example application without SERIDE_v0.2 ?>
<form method="post" action="./buyresult.php" >
Enter your Name(e.g. rrr):<br>
<input type="text" size=20 name="customer" value=" " /> <br>
Enter No.of shares you want to buy(e.g. 100): <br>
<input type="text" size=20 name="shares" value=" " /> <br>
<input type="submit" name="buyshares" value="Buy Shares" />
</form>
Figure 5.4 buyshares.php form
After the submitting the shares details by the user, the buyresult.php file read the form
values and display the result.
buyresult.php
<?php
$name=$_POST["customer"];
$shares=$_POST["shares"];
echo "Dear $name.. <br /> You purchased <b>$shares </b> shares.<br /> Thank
you.";
?>
Figure 5.5 buyresult.php output
The buyshares.php form is vulnerable to CSRF attack even it uses the POST request
for submitting the form. An attacker can view the source of the buyshares.php form
and he/she can do forgery by submitting the same form while loading the web page. If
a victim user opens following attacker controlled web page while purchasing shares
75
on a trusted web site. The attacker posts the following malicious code in his page. The
sample code for CSRF attack on buyshares.php form is as shown below:
CSRF attack using auto form submission (Buymalicious.php)
<?php //This is a malicious page without SERIDE_v0.2 protection ?>
<html>
<body onload="document.getElementById('form1').submit()">
<form id="form1" method="post" action="./buyresult.php" >
<input type="text" size=20 name="customer" value="rrr" /> <br>
<input type="text" size=20 name="shares" value="10000" /> <br>
</form>
</body></html>
Figure 5.6 CSRF attack using buymalicious.php file
Preventing CSRF attacks using token based mechanism (using SERIDE code):
To prevent from CSRF attack in the above buyshares.php application form, the
modified code is as follows:
buyshares.php
<?php
//This is an example application with SERIDE_v0.2
include("./seride.php");
?>
<form method="post" action="./buyresult.php" >
Enter your Name(e.g. rrr):<br>
<input type="text" size=20 name="customer" value=" " /> <br>
Enter No.of shares you want to buy(e.g. 100): <br>
76
<input type="text" size=20 name="shares" value=" " /> <br>
<?=seride_form();?>
<input type="submit" name="buyshares" value="Buy Shares" />
</form>
Figure 5.7 buyshares.php form (with SERIDE)
buyresult.php
<?php
//This program displays no.of shares purchased by the customer if he is valid.
include("./seride.php");
seride_check();
$name=$_POST["customer"];
$shares=$_POST["shares"];
echo "Dear $name.. <br /> You purchased <b>$shares </b> shares.<br /> Thank
you.";
?>
Figure 5.8 buyresult.php output (with SERIDE)
If a victim user opens following attacker controlled web page while purchasing shares
on a trusted web site. The attacker posts the following malicious code in his page.
buymalicious.php
<?php ?>
77
Hello, This is a sample malicious page.<br />
<body onload="document.getElementById('form1').submit()">
<form id="form1" method="post" action="./buyresult.php" >
<input type="text" size=20 name="customer" value="rrr" /> <br>
<input type="text" size=20 name="shares" value="10000" /> <br>
</form>
Figure 5.9 Error page to show the failure of CSRF attack on buyshares.php
The log file named ‘seride_log.txt‘gives the details of the attack origin information.
Figure 5.10 seride_log.txt file showing the CSRF attack origin information
5.3.4.2 Sample screenshots of SA-SERIDE Tool
The following web page screenshots shows the SA-SERIDE tool usage and its
experimental results based on the working procedure mentioned in section 5.3.1.
78
Figure 5.11 SA-SERIDE page to read the file name and domain name from the user.
Figure 5.12 SA-SERIDE tool providing an option to select a file by directory
browsing
79
Figure 5.13 SA-SERIDE submit page to display the domain and selected file after
directory browsing.
Figure 5.14 SA-SERIDE tool output after passing buyshares.php file as input. The
screenshot shows the both buyshares.php (actual) file and newbuyshare.php file.
80
Figure 5.15 Web page form of newbuyshares.php (with inclusion of SERIDE code).
Figure 5.16 Web page source code of newbuyshares.php (with generated one-time
tokens) to protect from CSRF attacks.
5.3.4 Future work
The current version of SA-SERIDE (i.e. saseride0.1) tool improved the SERIDE
(seride_v0.2) code and providing a semi-automated way to find all the valid form and
anchor tags. We can improve this tool by adding the following features:
1. The tool has to find all the URLs where seride_link() or seride_token() functions
are appended, and list those URLs in a separate file so that the user (i.e. administrator)
81
can view the list of files, and he can include the code [i.e. include (“seride.php”) ; and
seride_check(); function] in each file.
2. The SA-SERIDE tool creating a new file with by appending with the “new” word
to the filename. So user has to rename that file by removing the word “new” and has
to move the old file to another folder as backup copy. We can replace the old file with
the new file.
3. The current version of SA-SERIDE tool works by reading a file and generate a
new file, and it finds all anchor tags and form tags with valid URLs and appends
token generation functions to these URLs. If you make changes such as adding new
forms or anchor tags in the newly generated file and want to regenerate the file with
the help of SA-SERIDE tool, this tool will blindly append token generation functions
to all valid forms and anchor tags without checking the appended token functions. So
tool has to determine and append the token functions only to the URLs which does
not have these functions.
82
CHAPTER 6
CONCLUSION AND SCOPE FOR FUTURE WORK
6.1 Conclusion
The project addresses one of the most important problems faced by today’s web
applications, which is a Cross Site Request Forgery attack. In this attack, the trust of
web application in its authenticated users is exploited and it allows an attacker to
make arbitrary HTTP requests in the victim’s name. In this project we developed an
open source tool for preventing Image based CSRF attacks and the semi-automated
mechanism to the existing open source SERIDE code. We developed these two
heuristics for preventing the Cross Site Request Forgery attacks.
CSRF attacks using IMG elements are very simple and easy to exploit. In this
project, we have proposed a simple and effective solution to detect and prevent CSRF
attacks using image elements which use static URLs with a client-side proxy.
Webscarab proxy plug-in in the CSRFTester tool is used as a client-side proxy in our
implementation. This enables the users to protect themselves against image based
CSRF attacks using any browser. We are providing a client-side solution to prevent
the image based CSRF attacks.
Secret token validation mechanism is one of the most efficient mechanisms to prevent
CSRF attacks. SERIDE (SEssion RIding DEfender) is an open source PHP library
which uses secret token validation mechanism to prevent CSRF attacks successfully
at the server-side in all PHP web applications. In this project, we developed an open
source SA-SERIDE tool which is a semi-automated tool and an improved version to
the existing SERIDE code.
6.2 Scope for Future Work
We developed a solution to prevent image based CSRF attacks and developed an open
source SA-SERIDE tool. The scope for future work in these two modules is as
follows:
83
We are providing a client-side solution to prevent the image based CSRF attacks. Our
solution is preventing all the image based CSRF attacks except the JavaScript image
objects. Validating JavaScript image objects is yet to be implemented. The existing
code can be extended to include this functionality to protect against JavaScript image
object based CSRF attacks. We used CSRFTester tool and Webscarab proxy plug-in
present in that tool as the proxy to execute and test our implementation. A separate
GUI need to be implemented to make it as a separate tool. Usage of dynamic image
URLs in the webpage is very less as compared to static image URLs and these are
used mainly for advertisements. So blocking advertisements is advantageous to the
users, but some users may want to see the advertisement or some websites restrict the
user to login to the site only after viewing the advertisement. We can provide more
number of options to the user such as allow or block the dynamic images, view the list
of images in the webpage etc. This solution can also be made browser specific by
creating an add-on to the browsers like Firefox.
The current version of SA-SERIDE (saseride0.1) tool is a semi-automated and an
enhancement to the SERIDE code. We can add additional features as explained in
section 5.3.4 to this tool and make this tool as fully automated SERIDE tool.
84
BIBLIOGRAPHY
[1] Martin Johns and Justus Winter. RequestRodeo: Client side protection against
sessionriding. In Proceedings of the OWASP Europe 2006 Conference, May 2006.
[2] Nenad Jovanovic, Engin Kirda, and Christopher Kruegel. Preventing cross site
request forgery attacks. In IEEE International Conference on Security and
Privacy in Communication Networks (SecureComm), 2006.
[3] A.Barth, C.Jackson, and J.C.Mitchell. Robust defences for cross site request
fogery. In Proc. ACM Conference on Computer and Communications Security
(CCS), Oct, 2008.
[4] OWASP top 10 2007. http://www.owasp.org/index.php/Top_10_2007. May 2009.
[5] Nexus. SERIDE - PHP library for session riding protection. http://projects.play-
-hack.net/project.php?id=3. May, 2009.
[6] OWASP Top ten most critical web application security vulnerabilities.
Whitepaper. http://www.owasp.org/index.php/Top- 10-2007, May 2009.
[7] Kelly Jackson Higgins, "CSRF Vulnerability: A 'Sleeping Giant'", http://www.
darkreading.com/security/app-security/showArticle.jhtml?articleID= 208804131,
Apr, 2009.
[8] Cross-Site Request Forgery. http://www.owasp.org/index.php/Cross-Site_Request
_Forgery. May, 2009.
[9] William Zeller and Edward W.Felten, Cross-Site Request Forgeries: Exploitation
And Prevention. http:// www.freedom-to-tinker.com/sites/default/files/csrf.pdf.
May 2009.
[10] Robert Auger. The Cross-Site Request Forgery (CSRF/XSRF) FAQ. http://www.
cgisecurity.com/csrf-faq.html. Apr, 2009.
[11] OWASP CSRFTester Project. http://www.owasp.org/index.php/Category:
OWASP_CSRFTester_Project, May, 2009.
[12] Cross-site request forgery. http://en.wikipedia.org/wiki/Cross site request
forgery. May, 2009.
[13] Renaud Feil. Louis Nyffenegger. Evolution of cross site request forgery attacks.
November 2007. http://www.springerlink.com/content/h65wj72526715701/
fulltext.pdf. May 2009.
85
[14] Peter w. June 2001, cross site request forgeries, http://www.tux.org/~peterw/
csrf.txt, May 2009.
[15] chuck willis. Preparing for the Cross site request forgery defense. http://www.
blackhat.com/presentations/bh-dc-08/Willis/Whitepaper/bh-dc-08-willis-WP.pdf.
Mar 2009.
[16] Jesse Burns. Cross Site Request Forgery, An introduction to a common web
application weakness. https://www.isecpartners.com/files/CSRF_Paper.pdf. Mar
2009.
[17] David Airey. Google’s Gmail security failure leaves my business sabotaged,
December 2007. http://www.davidairey.co.uk/google-gmail-security-hijack/. Mar
2009.
[18] Cyrill Brunshewiler. Cross Site Request Forgery. http://www.csnc.ch/misc/files/
publications/compass_event08_csrf_bru_v1.0.pdf. Sept, 2008.
[19] J.Franks, P.Hallam-Baker, et al. Http authentication: Basic and digest access
authentication. RFC 2617, http://ietf.org/rfc/rfc2617.txt, June 1999.
[20] D.Kristol and L.Montulli. HTTP state management mechanism. RFC 2965,
http://www.ietf.org/rfc/rfc2965.txt, October 2000.
[21] T.Dierks and C.Allen. The tls protocol version 1.0. RFC 2246, http://www.ietf.
org/rfc/rfc2246.txt, January 1999.
[22] Mario Heiderich. CSRFx, 2007. http://php-ids.org/category/csrfx/. Mar 2009.
[23] Eric Sheridan. OWASP CSRFGuard Project, 2008. http://www.owasp.org/index.
php/CSRF_Guard. Mar 2009.
[24] Aaron Johnson. The Referer header, intranets and privacy, February 2007. http://
cephas.net/blog/2007/02/06/the-referer-header-intranets-and-privacy/. Mar
2009.
[25] Amit Klein. Exploiting the XMLHttpRequest object in IE-Referrer spoofing and
a lot more. September 2005. http://www.cgisecurity.com/lib/XmlHTTPRequest.
shtml. Mar 2009.
[26] Mozilla Foundation. Security advisory 2005-58, September 2005. http://www.
mozilla.org/security/announce/2005/mfsa2005-58.html. May2009.
[27] Prototype JavaScript framework. http://www.prototypejs.org/. Mar 2009.
[28] Nexus, Prevent CSRF. http://files.playhack.net/papers/preventcsrf.txt. May 2009.
86
[29] Internet Explorer "mhtml:" Redirection Disclosure of Sensitive Information.
http://secunia.com/advisories/19738/. May 2009.
[30] Mike Champion, Steve Byrne. Document Object Model (core) level1. http://
www.w3.org /TR/REC-DOM-Level-1/level-one-core. html#ID-E067d597. May,
2009.
[31] The web hacking incidents database. http://www.webappsec.org/projects/whid/
byid_id_2008-05.shtml, 2008.
[32] Chuck Musciano, Bill Kennedy. HTML & XHTML: The Definitive Guide, Fifth
Edition. Aug, 2002.
[33] Image-Inline Image. http://htmlhelp.com/reference/html40/special/img.html.
May, 2009.
[34] HTML input type attribute. http://www.w3schools.com/TAGS/att_input_type.asp.
May, 2009.
[35] Sapna satish. CSRF- The hidden menace. http://palisade.plynt.com/issues/2008
Jun/cross-site-request-forgery. June, 2008.
[36] Regular expressions. http://java.sun.com/docs/books/tutorial/essential/regex/
index.html. May, 2009.
[37] XAMPP for windows. http://www.apachefriends.org/en/xampp-windows.html,
May, 2009.
[38] WampServer-Apache, MySQL, PHP on Windows. http://www.wampserver.com/
En/. May, 2009.
87
APPENDIX I
OWASP THE TEN MOST CRITICAL WEB
APPLICATION SECURITY VULNERABILITIES
The primary aim of the OWASP (Open Web Application Security Project) Top 10 is
to educate developers, designers, architects and organizations about the consequences
of the most common web application security vulnerabilities. OWASP discusses each
of the vulnerability in detail along with the protection measures to be taken to protect
the application from these vulnerabilities. The following table provides a brief
description about the top 10 vulnerabilities listed in the OWASP Top 10 2007 [4].
Vulnerability Description
A1 – Cross Site
Scripting (XSS)
XSS flaws occur whenever an application takes user supplied
data and sends it to a web browser without first validating or
encoding that content. XSS allows attackers to execute script in
the victim’s browser which can hijack user sessions, deface
web sites, possibly introduce worms, etc.
A2 – Injection
Flaws
Injection flaws, particularly SQL injection, are common in web
applications. Injection occurs when user-supplied data is sent
to an interpreter as part of a command or query. The attacker’s
hostile data tricks the interpreter into executing unintended
commands or changing data.
A3 – Malicious File
Execution
Code vulnerable to remote file inclusion (RFI) allows attackers
to include hostile code and data, resulting in devastating
attacks, such as total server compromise. Malicious file
execution attacks affect PHP, XML and any framework which
accepts filenames or files from users.
A4 – Insecure
Direct Object
Reference
A direct object reference occurs when a developer exposes a
reference to an internal implementation object, such as a file,
directory, database record, or key, as a URL or form parameter.
Attackers can manipulate those references to access other
objects without authorization.
88
A5 – Cross Site
Request Forgery
(CSRF)
A CSRF attack forces a logged-on victim’s browser to send
a pre-authenticated request to a vulnerable web
application, which then forces the victim’s browser to
perform a hostile action to the benefit of the attacker.
CSRF can be as powerful as the web application that it
attacks.
A6 – Information
Leakage and
Improper Error
Handling
Applications can unintentionally leak information about their
configuration, internal workings, or violate privacy through a
variety of application problems. Attackers use this weakness to
steal sensitive data or conduct more serious attacks.
A7 – Broken
Authentication and
Session
Management
Account credentials and session tokens are often not properly
protected. Attackers compromise passwords, keys, or
authentication tokens to assume other users’ identities.
A8 – Insecure
Cryptographic
Storage
Web applications rarely use cryptographic functions properly
to protect data and credentials. Attackers use weakly protected
data to conduct identity theft and other crimes, such as credit
card fraud.
A9 – Insecure
Communications
Applications frequently fail to encrypt network traffic when it
is necessary to protect sensitive communications.
A10 – Failure to
Restrict URL
Access
Frequently, an application only protects sensitive functionality
by preventing the display of links or URLs to unauthorized
users. Attackers can use this weakness to access and perform
unauthorized operations by accessing those URLs directly.
Table 1: OWASP Top 10 Vulnerabilities for 2007
89
APPENDIX II
CSRFTester Tool
This appendix describes how to utilize the OWASP CSRFTester tool to generate test
cases during an application security assessment. To download the tool, please visit the
OWASP CSRFTester project page at https://www.owasp.org/index.php/
Category:OWASP_CSRFTester_Project.
Quick Steps
The following is an outline of the steps necessary to launch and utilize the
CSRFTester:
1. Update the JAVA_HOME environment variable in run.bat
2. Double-click run.bat
3. Configure browser to proxy through CSRFTester
4. Record the execution of a business function
5. Modify the parameters of the recorded business function
6. Generate an HTML report that carries out the business function
7. In a separate browser window (and a separate user), view the generated
HTML file
8. If the action was successfully carried out, then the application is
vulnerable to CSRF
Launch OWASP CSRFTester
The CSRFTester distribution contains three files: run.bat, OWASP-CSRFTester-
1.0.jar, and concurrent.jar. The run.bat script configures the classpath to include the
required jars and invokes the appropriate main class. Currently, the batch script
assumes your JDK runtime exists under C:\AppSecWorkbench\jdk16\jre. Obviously,
this will not be the correct location of your JVM. Make sure you update the
JAVA_HOME environment variable in run.bat before attempting to execute the
batch file. Assuming proper configuration, executing run.bat should launch
CSRFTester. If an error occurs, evident when the command line interface quickly
90
disappears, consider opening up a separate CLI and 'CD' directly to the folder of your
run.bat file and execute it via command line. Any errors that may occur will display to
stdout.
Record Execution of Business Functions
Once the CSRFTester loads successfully, we must record a transaction that we want
to test for CSRF. First, we must configure the browser to proxy all HTTP traffic
through CSRFTester. We can configure this proxy behavior in IE using the Tools
menu. Select Tools -> Internet Options -> Connections -> LAN Settings to get the
proxy configuration dialog.
CSRFTester defaults to using port 8008 on localhost for its proxy. You need to
configure IE to relay requests to CSRFTester, rather than fetching them itself, as
shown in the above image. Make sure that all checkboxes are unchecked, except for
"Use a proxy server". Once you have configured IE to use the proxy, select Ok on all
91
dialogs to get back to the browser. Browse to a non-SSL website, and then switch to
CSRFTester.
If the proxy was successfully configured, CSRFTester will generate debug messages
to stdout for all subsequent HTTP requests generated by your browser. At this point,
we need to locate a particular business function that we want to test for CSRF.
Browse to the page where the business function (or functions) is first "loaded". Once
this page is located, select the "Start Recording" button in CSRFTester and execute
the business function or functions. Once complete, click the "Stop Recording" button
within CSRFTester. You'll notice that the list on the main screen now has a serious of
requests recorded. These are all of the GET/POST requests generated by our browser
while executing the business function(s). By selecting one of the rows in the list, we
now have the ability to modify the parameters that were used to execute the business
function. We can modify the "query string" parameters and "form" parameters
through their respective panes on the bottom half of the screen. Note that these are the
values we wish to trick the end user into submitting. Once all of the parameters have
been modified to contain your desired values, we are now ready to begin generating
HTML reports.
Generate HTML Reports
The HTML reports generated by the CSRFTester tool are used to carry out the CSRF
test cases against other users of the web application. To generate a report, we first
must select a "report type". The report type determines how we want the victims
browser to submit the previously recorded requests. There currently exists 5 possible
reports: forms, iFrame, IMG, XHR, and Link.
Forms: This report type will submit the request(s) using auto-posting forms
iFrame: This report type will submit the request(s) using and auto-submitting iframe
tag.
IMG: This report will submit the request(s) using the <img src="..."/> tag
XHR: This report will submit the request(s) using XMLHttpRequest. Note that this is
subject to the same origin policy.
92
Link: This report will submit the request(s) when the user clicks a link.
Once a report type is selected, you can optionally launch the newly generated report
in your browser. To enable/disable this option, check/uncheck the "Display in
Browser" checkbox next to the "Generate HTML" button in the bottom right-hand
corner. Finally, we can click the "Generate HTML" button to create the HTML report
that will submit our recorded (and possibly modified) actions. To carry out the test
case, open a new browser instance, authenticate as another user with access to the
same business function(s), and have that user/browser launch the newly created
HTML report file. If the action was carried out after viewing the file in the same
browser window that was used to authenticate the new user (i.e. the victim), then that
particular business function is vulnerable to cross-site request forgery.
93
BIO-DATA
Contact Address: S/o Ramisetty Venkateswarlu,
Chejarla (Post), Nekarikallu (Mandal)
Guntur (Dist.) Andhra Pradesh (State) Pin – 522615.
E-mail Address: [email protected]
Qualification: M.Tech. (Computer Science & Engineering – Information Security)
Publication(s)
[1] Ramarao R, Radhesh M, Alwyn R. Pais. “Preventing Image based Cross Site
Request Forgery Attacks”. ICSCF09, Proceedings of Indo-US conference &
workshop on Cyber Security, Cyber Crime & Cyber Forensics. Kochi, India.
(19-21 August 2009).
Related Documents
