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.
–>
About ISHIR:
ISHIR is a Dallas Fort Worth, Texas based AI-Native System Integrator and Digital Product Innovation Studio. ISHIR serves ambitious businesses across Texas through regional teams in Austin, Houston, and San Antonio, supported by an offshore delivery center in New Delhi and Noida, India, along with Global Capability Centers (GCC) across Asia including India, Nepal, Pakistan, Philippines, Sri Lanka, and Vietnam, Eastern Europe including Estonia, Kosovo, Latvia, Lithuania, Montenegro, Romania, and Ukraine, and LATAM including Argentina, Brazil, Chile, Colombia, Costa Rica, Mexico, and Peru.
Get Started
Fill out the form below and we'll get back to you shortly.


