Share

A Cross Site Request Forgery (CSRF) attack is one of the widely used web application vulnerability. Basically, an attacker will use CSRF to trick a victim into accessing a website or clicking a URL link that contains malicious or unauthorized requests. In other words, we can say that the victim unintentionally runs a script in the browser which takes advantage of the logged in session to a particular site. Therefore, CSRF attacks can be performed over GET or POST requests.

 

How does the attack work?

 

There are number of ways in which an end-user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a malicious request for our victim to execute. Let us consider the following example: User X wishes to transfer $100 to User Y using dummybank.com. The request generated by X will look similar to the following:

 

POST http://dummybank.com/transfer.php HTTP/1.1

Content-Length: 19;


acct=Y&amount=10


However, User Z notices that the same web application will execute the same transfer using the following URL parameters:

GET http://dummybank.com/transfer.php?acct=Y&amount=100 HTTP/1.1

Z now decides to exploit this web application vulnerability using X as her victim. Maria first constructs the following URL which will transfer $100,000 from X’s account to her account:

http://dummybank.com/transfer.php?acct=Z&amount=100000

Now, that her malicious request is generated,  Z must trick X into submitting the request. The most basic method is to send X an HTML email containing the following:

<a href="http://dummybank.com/transfer.php?acct=X&amount=100000">
You Have Won 1,000,000 million dollars</a>

Assuming X is authenticated with the application when she clicks the link, the transfer of $100,000 to Z’s account will occur.

Solution against CSRF attack

The use of TOKENS come into play when we have to make our web application secure from CSRF attacks. A token is set of alpha numeric characters which will generate randomly and appended with each HTTP request. It should have a limited life-time which will make your app more secure.

The basic idea would be:

  • When generating the page :
    • generate a unique token
    • store it in the user’s session
    • and place it in the links of the page — which would look like this http://dummybank.com/transfer.php?token=ASGFD34FS3AAH
  • When the transfer page is called :
    • Check if the token is present in the URL
    • Check if it’s present in the user’s session
    • If not,   redirect it to the previous page from where the request has come with some flash message. 

The idea there is:

  • Tokens don’t have a long life-time, and are hard to guess
  • Which means your attacker :
    • Has only a window of a few minutes during which his injection will be valid.
    • Will have to be good at guessing.
    • Will have to generate a different page for each user.

 

 

Posted by

Siddharth

 

Disclaimer: Developer’s Corner Section of ISHIR blog is contributed and maintained by independent developers. The content herein is not necessarily validated by ISHIR.


–>

Leave a Reply

Your email address will not be published. Required fields are marked *