Skip to main content

[Tutorial] Cross Site Request Forgery Attack

Cross Site Request Forgery Attack – Less known but dangerous
Cross Site Request Forgery (CSRF or XCRF) is one of the top 10 OWASP website vulnerabilities. But the most important about this vulnerability is that the vulnerability is less known so most of the people do not know that this vulnerability exists. You will find most of the website vulnerable to this attack.
What is CSRF: CSRF is the malicious exploit in which an attacker sends legitimate commands to a website from a user without his permission. For sending legitimate commands, attacker uses victim’s web browser. Attacker uses victim’s web browser to send valid requests to a website without user’s interaction on that request. This attack is also known as session riding because attacker uses the session of the victim to perform the requests.
People always confuse this vulnerability with XSS (Cross-Site Scripting) and those who know says that protection against XSS attack also make website secure against the CSRF attack. But XSS and CSRF are different type of attacks. Cross-Site Scripting exploits the trust of a client for the website or application. But CSRF exploits the trust of a website on the user’s browser. If the request is being made by the user’s web browser, then website thinks that it is made by the user itself.
Overview of the CSRF attack: CSRF attack is performed by using victim’s web browser. In this attack there are 3 things which are involved.
1.       Victim: The person whose session is being used by the attacker.
2.       Trusted website: Website on which the commands being sent by the attacker using victim’s web browser.
3.       Malicious website: Website used by the attacker to ride the session of the user to send the requests on the trusted website using user’s web browser. This website site injects a HTTP request for the trusted site into the victim user session compromising its integrity.
Suppose there is a user who have logged in into a website A. After logging in. website has started a session for that login. After some time user has visited the malicious website B which contains a malicious link posted by the attacker which sends some request on the website A. In This case, if the user will click on that link, a request is being send to the website A with the valid session started by user.
Now take a look on the live example on a bank website.
A user logged in into a bank website with his login details. In this case a valid session is started by the website on the user’s web browser.

Figure 1: user login in a bank website
This website has a form like this:
<form action="" method="GET"> Recipient: <input type="text" name="receiver"> Amount : <input type="text" name="amount"> <input type="text" name="sender" value=”taken_from_session”> <input type="submit" value="transfer"> </form>
This is the form on the bank website to transfer the funds to the other person’s account. Here the hidden field is used for the sender’s account. Its value is taken from the database according to the user’s session. So the account will be the account of the person who has started the session on the website.
After the submission of the form this will send the data to the page transferfunds.php with data submitted. You can see the URL of the target page like this’s_account&amount=amount_to_be_transferred&reciever=receiver’s_account
This form sends GET requests. The GET request could be originated in several different ways:
1.       By the user, who is using the actual web application;
2.       By the user, who types the URL directly in the browser;
3.       By the user, who follows a link (external to the application) pointing to the URL.
If the user knows the form structure and the website is vulnerable to the attack, he can exploit this vulnerability to transfer the funds to his account from the user’s account.
Now attacker force user to open a malicious website in other tab which has a malicious link like this.
Take a look on the link. This link sends a GET request to the bank website to transfer the funds from the account of logged in user to the account of someone else account. Here is an example of malicious link using an image tag. Browser does not restrict image tag for any specific type of image extension so it can also point to any webpage.
Attacker can also use:

Figure 2: Attacker using victim’s browser to perform action
There are many ways to send this link to the victim.
1.       By a third party website where it is posted as an image link or scripting tag
2.       By sending link in Email.
3.       Malicious link in all external documents which can execute scripts.
4.       On instant messaging
Many times attacker uses URL shorten service to generate a short URL which will redirect user to original URL.
Some Points about the attack: I have shown a simple attack example on a bank website using a form which uses GET method to submit data without the original user’s interaction in the action. But this attack is not as simple as it is shown in the example attack. I said that the attack is used the website trust on the user’s browser. But this attack is not limited to the browsers. Attacker can also embed into a word document, Flash File, Movie, RSS or Atom web feed, or other document format allowing scripting.
The example shown above uses the GET method for the attack. But it does not mean that the applications using GET methods only vulnerable to the attack. POST forms can be exploited by creating fake forms if the form structure is known.
Limitation: You have seen the process how an attacker can exploit this vulnerability. But there are some limitations of CSRF attack. The success of CSRF depends on many factors which can be there at the same time. This is a blind attack which has not good success rate. These are some factors.
1.       The attacker must find a website that is vulnerable to the attack does not check referrer header.
2.       Attacker should have the idea of the structure of that website and its forms.
3.       The user must be logged in into the website while clicking on the malicious link.
These factors should be true at the same time while attacker is performing the attack.
How to check a website is vulnerable to CSRF? This vulnerability exists due to the lack of knowledge of website developers. But website developers can protect their website by manually checking all the web forms. To check a website for this vulnerability, create a duplicate form and host it on some other domain and then try to send request to original website.  In case of GET form, you can directly create a request link which can be posted on any website.
If any website allows attacker to perform a legitimate website function using a static URL or POST request then there is the possibility of this attack. If this command is performed through GET then it is a much higher risk for the website. If the site is purely POST, an attacker could craft a website form on the website A (some other website) and using JavaScript auto submit form function to submit the form to a target website B. If the web application containing the CSRF payload uses a browser component that runs in the local zone, then sending remote POST requests to any website is possible using XMLHTTP or similar objects. A quick test would involve browsing the website through a proxy such as Paros and record the requests made. At a later time perform the same action and see if the requests are performed in an identical manner (your cookie will probably change). If you are able to perform the same function using the GET or POST request repeatedly then the site application may be vulnerable.
Protection against CSRF: This attack is easy to prevent. But most of the website developers do not know about this attack. So you will see many websites vulnerable to this attack. These are the main ways which can be used to protect web applications against this attack.
1.       Use of random TOKENS: This is the main and most successful protection against this attack. Use random tokens with a form submission each time when a user submit a form. It’s very difficult to guess the random token pattern. But those random values of the token must be unpredictable. This is the best way to protect against the attack. You have seen the above form example. We can protect that form by using the code below:
action=""  method="GET">
Recipient: <input id="acpro_inp0" name="receiver" type="text" />
Amount : <input id="acpro_inp1" name="amount" type="text" />
<input id="acpro_inp2" name="sender" type="text" value="”taken_from_session”" />

The validity of the token can also be limited to a small piece of time, such as 3-5 minutes. We have stored token In the session variable and it is unique to a user. Attacker must know the token to submit this form via external ways.
2.       Limiting the lifetime of cookies: Website must have some limited time for the authentication cookies. If user is inactive for some fixed time, the session must be expired. So user will have to login again for performing some other action. In this case, if the attacker is trying to perform CSRF attack with some valid HTTP request, request will not be accepted. User will have to login again. And why will he login if he had not sent the request?
3.       Use POST method in forms: POST method is more secure than GET method. If GET method is used in a form, all the submitted data and variables can be seen on the URL as query string parameter on the address bar. But POST method submits data in secure manner. But this is not a good protection and post forms can also be exploited. It can only increase attacker’s effort in exploiting the vulnerability.
4.       Check for the referrer website in each request: Always check the header of the request and check from which web page the request is being made. And perform action according to the request if the referrer website valid. A request for money transfer on the bank website must be sent from the bank website itself and the page which is designed for the money transfer. All other requests will be attack.
But attacker can easily modify header information too, if he knows the exact structure of the website and referrer page for the form. He can change that to the original one in the request headers. So this protection method is also limited.
5.       Damage limitation: This is not the protection, but it reduces damage caused by the vulnerability. For example if an attacker have manage to perform CSRF on a website then any action done by him will require an authentication every time to limit the damage. Amazon uses damage limitation to reduce the damage by authenticating user at each step.
Conclusion:  CSRF is a website vulnerability which is less known to website developers so it exists and can be seen in many websites. This vulnerability was found in Gmail 5 years back on January 2007. There are many famous websites which are still vulnerable to this type of attack. It is really difficult to protect against this attack, but there are many ways which can help to protect against this. The most effective way is use of random token generator. This is used by many websites to protect against CSRF. Amazon uses damage limitation to protect against this attack.
Users who want to protect themselves against the attack must know that they cannot do anything. If they want to protect their session being used, they should logout the website just after the usage. And avoid browsing other website while using some secure session website.