CSRF – Cross Site Request Forgery.

Posted on 15/11/2009 by


Today we talk about Cross Site Request Forgery (also known as XSRF) abbreviated in CSRF from which its pronunciation has come from the friendly name called “Sea Surf”.. (it bascially means surfing on the net)…Cross-site request forgery (ie, CSRF) has been referred to as a Web security sector number of loopholes in the “sleeping giant” it has a power and it will not show to a full extent and its level of threat which “reputation” will be shown. This article will briefly explain the loopholes and details of the reasons for this attack is located as well as the black-box testing against the loopholes and gray-box testing methods and specific examples finally mention a number of recommendations to prevent the attack, I hope the readers of this article and the safety tests can be a source of inspiration. We all need to understand what are (CSRF) Cross-site request forgery is an end-users currently log in at the Web application to perform the operation of non-intention of attack methods. As long as the attacker has some social engineering tricks such as by e-mail or chat softwares to send the link and the attacker will be able to force a Web application using to perform the selection operation of the attacker.

Example: If users log into the internet banks go and view their deposits he/she did not quit the network banking system go enjoy their own forum go irrigation and if the attacker at the forum carefully construct a malicious link and to induce the user clicks on the link then the user at the network bank account funds may be transferred to the attacker specified account.
When CSRF attacks against ordinary users that the data will be the end of the user and operational directives pose a serious threat when attacks by the end user with an administrator account when CSRF attacks will threaten the entire Web application.

This kind of vulnerability which is very common and under estimated permits to make a victim user to send any kind of HTTP request to a website in which he/she 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(Its aso a default saving format for Dreamwever) doing these actions which really complicates the identification of a CSRF attack.

Commonly when a user logs into a trusted website he/or she has to verify the system and will flag the  person with a “token” that tells the website that the current user is 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 the single user.

Anytime this user logs into the website with his own credentials he/she will be flag-ged and a new session will be generated and meanwhile an attacker could easily make some unauthorized actions in the “ward” (area) of that website 😉

It could look  quite un-dangerous because only an idiot user will accept any kind of request that will  own authentication: great mistake! Don’t ever understimate the power of a sweet Cookie! 😛
Cookies are the aim of the most XSS attacks because it permits an instant access to any kind of confidential and private service an user has privileges on: the CSRF is even more powerful because the current session cannot be avoided easily if the website doesn’t provide very short temporary cookies.

Difference between XSS and CSRF

Actually, what’s the real difference between XSS and CSRF? They look very similar!
As a matter of fact they’re quite similar, but there’s a core difference that makes the two vulnerabilities strictly opposed each other.
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/her 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.

Okay… now that we got a general idea of what CSRF is lets try to get in to some simple examples. Assure that for example: a user is subscribed into a website that provides some particular services and also 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/her own private pages. Assure also that the website is maybe an 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>
<!– EOF –>



Posted in: Hacking, Networking