CSRF, or cross-site request forgery, occurs when a malicious website causes a user's browser to perform unintended actions on a website where the user is authenticated. Attackers can use CSRF to perform actions like transferring money from a user's bank account without their knowledge or consent. To prevent CSRF, websites should use POST requests instead of GET, assign random tokens for requests, and include CSRF protections in frameworks. Major sites have been vulnerable to CSRF in the past, so defenses against it are important.

1. CROSS-SITE REQUEST FORGERIES
AKSHAY BHARDWAJ
INTRODUCTION
Cross-Site Request Forgery (CSRF, pronounced as see-surf) occurs when a website causes a
user’s browser to perform an unintended action on a website where the user has some authority.
CSRF attacks are also known as Cross-Site Reference Forgery, XSRF and Session Riding. Web
developers mostly assume that defenses against Cross-Site Scripting (XSS attack) also protect
against CSRF attacks. But this is not true as the nature of both attacks although similar, have a
few differences. The National Vulnerability Database’ website defines CSRF attacks as:
“Failure to verify that the sender of a web request actually intended to do so. CSRF attacks can
be launched by sending a formatted request to a victim, then tricking the victim into loading the
request (often automatically), which makes it appear that the request came from the victim.
CSRF is often associated with XSS, but it is a distinct issue.”[1]
CSRF attacks are particularly dangerous because they are largely ignored by the web
development community. If these attacks are successful, they have the potential to do malicious
things on websites like: transferring money from a user’s bank account to an undisclosed bank
account without the user’s knowledge, retrieve user’s email address, intrude over a user’s
privacy etc. All these malicious acts can be accomplished by the attacker without the knowledge
or approval of the user.
HOW CSRF WORKS?
Usually the image tag in HTML is used for CSRF attacks, where the attacker puts a URL that
does the malicious act (through a command) instead of just putting a URL to the image. This is
very vulnerable as the server does not know that the difference between a URL for just an image
and a URL to direct the user to the attackers webpage. The server handles all URL’s the same
way.
A CSRF attack does not attempt to steal the user’s username and password in order to control the
session id, unlike the Cross-Site Scripting (XSS) attack which directs the user from their home
Page 1

2. page to a third party site through a link, which requests for the user’s username and password,
using which malicious acts can be performed. For this reason a CSRF attack is more difficult to
identify as it happens without the user’s knowledge.
Example
Probably the most malicious act would be to use a CSRF attack to transfer money out of a user’s
bank account to an undisclosed bank account. This can be accomplished very easily by the
attacker by directing the user to a link like this:
http://www.somebank.com/transfer.cgi?amount=15156167&rcpt=undisclosed
If the attacked user is logged into the bank’s website, the browser would attach the valid session
cookie to this request and hence the money transfer could be accomplished. The CSRF attack can
be lucidly explained by the diagram below:
Figure 1: The web browser has established an authenticated session with the trusted site. Trusted
action will only be performed when the web browser makes the request over the session. [2]
Page 2

3. Figure 2: This is a valid request. The browser attempts to perform the trusted action. The site
also gives authority to the browser to perform the said action. [2]
Figure 3: This is a CSRF attack. Here the attacking site is causing the user’s browser to send a
request to the trusted site for an authentication, which it gets! And hence the browser performs
the action. Here the trusted website is authenticating the browser without knowledge of the user
in any way! [2]
POSSIBLE DEFENSES AGAINST CSRF
There are a few possible defenses that can be applied to prevent CSRF attacks:
Using POST method instead of GET [4]
The POST method is a more secure way of handling more important operations than the GET
method i.e. if the POST method is employed, then the attacker will not be able to exploit the
vulnerability of the GET method by sending a <img> tag as a link to a malicious webpage.
For example:
<form method = “POST” action = “formaction.php”>
Name: <input type=”text” name=”username”>
Email: <input type=”text” name=”email”>
</form>
Page 3

4. The above form shows how information is sent using the POST method.
<?php
$person1=$_POST[‘username’];
$reply_to=$_POST[‘email’];
?>
The PHP script above shows how it receives the data through $_POST
Now in this case if an attacker tries to use an image tag containing a URL which uses the GET
method, nothing will be accomplished as the script only receives data sent by the POST method.
Assign a random token for confirmation [4]
Avoiding the GET method is good but the POST method is still vulnerable if the attacker is
smart enough. To avoid this situation, the most widely used method is to assign a randomly
generated token or high strength encryption password provided to the user by email or otherwise
every time the user wants to go to another page by clicking on a certain link while being logged
in. By doing so, the attacker although might be able to direct the user to a malicious page, he will
not be able to steal the session cookie as only the user will have the randomly generated
password required to access that webpage.
CONCLUSION
CSRF attacks should be taken more seriously as they are difficult to detect. Apart from the above
measures, creators of frameworks should include CSRF protection so that sites built on such
frameworks will not be vulnerable to CSRF attacks. CSRF is said to have attacked major
websites like Gmail, NYtimes, Netflix, ING Direct, YouTube, Metafilter and hence cannot be
ignored.
Page 4

5. REFERENCES
[1] The National Vulnerability Database website
http://nvd.nist.gov/home.cfm
[2] Zeller, William, and Edward W. Felten. “Cross-Site Request Forgeries: Exploitation and
Prevention.”(2008), Princeton University.
[3] cgisecurity.com
http://www.cgisecurity.com/csrf-faq.html#discovered
[4] Clarinsson, Richard and Samuel Magunsson. “The PHP programmer’s guide to secure code”.
School of Mathematics and Systems Engineering,
Vaxjo University, 2005.
[5] Johnston, Paul.”Authentication and Session Management on the Web.”
2004. GIAC Security Essentials Certification Practical
Assignment Version 1.4b.
[6] Suhina, Vanja. “Exploiting and Automated Detection of Vulnerabilities in Web
Applications.” 2007
Page 5