Page 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 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 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 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 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