Cross-site request forgery (CSRF) is a common web application vulnerability, in which an attacker/hacker fools the victim’s browser into generating requests to a website which performs specific actions on behalf of the logged in user or the victim.
The web server receiving the request and performs the desired actions of the request, which looks similar to the normal request that is generated by the users’ browser. CSRF vulnerabilities can change a lot in severity; good ones can modify settings or post on someone’s side, but critical ones can end with password change, account takeover, and so on.
CSRF vulnerability has been commonly highlighted in the OWASP Top-10 vulnerability list for the past few years. It’s a generally confused vulnerability by the developers who usually miss understanding the root cause of the issue, thereby performing half-baked solutions to prevent the CSRF problem.
Imagine a banking web application that transfers funds to another user based on his username. The following URL is created for the same:
“https://bank.example.com/transfer/money?username=John&amount=500”
So, assuming that the user is logged in and the above URL is received by the server of the web application, it will simply transfer 500 dollars to the username John.
Now this is a normal process until someone with evil aim creates a webpage with the following content and hosts it somewhere:
<html> <head> </head> <body> <img src=”https://bank.example.com/transfer/ money?username=Attacker&amount=2500″/> </body> </html>
If a logged in user (victim) of the banking application views the above page, the browser will try to load the image, which truly is a URL to transfer money to the attacker with the amount 2500 dollars.
