Web Application Vulnerability – CSRF
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:
However, User Z notices that the same web application will execute the same transfer using the following URL parameters:
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:
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:
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.
Disclaimer: Developer’s Corner Section of ISHIR blog is contributed and maintained by independent developers. The content herein is not necessarily validated by ISHIR.
- Microsoft Windows Server
- Open Source
- Managed Security Services
- Artificial Intelligence
- PSD Slicing
- Developers Corner
- Pay Per Click (PPC)
- Mobile Application Development
- Managed Hosting
- Microsoft .NET Custom Development
- Software Testing
- Microsoft SharePoint Development
- Microsoft Windows Azure
- Offshore Development
- Outsourcing Software Development
- Microsoft Office 365
- Non-Profit IT
- Application Virtualization & Packaging
- Digital Marketing
- Search Engine Optimization (SEO)
- Social Media
- Website Development
- Cloud Computing