Surprising Facts About Cross Site Request Forgery

Cross Site Request Forgery (also known as CSRF) is a web application vulnerability in which attacker's website forces victim's browser to send malicious requests to the vulnerable website in which the victim is currently authenticated.

To perform Cross Site Request Forgery attack, attacker tricks a logged-in user by using social-engineering techniques to perform some tasks on behalf of the user without their knowledge.

The vulnerable web application is unable to differentiate between a legitimate user request and requests initiated a malicious website.

Why Do We Care About Cross Site Request Forgery ?

The damage caused by a csrf attack can vary depending on the web application's functionality that is vulnerable to csrf attacks. Following are the problems that can be caused by cross site request forgery.

Impersonation and identity riding: After a csrf attack is successful, an attacker can make requests as he or she wishes to execute on behalf of the user.

Modification of account information: If any csrf vulnerability is found on account modification page, then attacker can modify account details of the user after successfully executing this attack.

Compromised admin account: If a csrf vulnerability exists in an admin account, attackers can compromise admin account.

Understanding Cross Site Request Forgery Attack

To understand csrf attack, at first we need to know the basics of how cookies and sessions work in a web application.

How cookies and sessions Work ?

Suppose, a user Jhon visits a webpage www.example.com and then he tries to login to his account in that website. After entering his credentials and pressing the login button, the server receives a login request with username / email and password from Jhon.

Then server performs verification of whether that credentials are valid or not. If it is found to be valid, then a cookie is created on the server-end along with a unique session id that is generated by the server itself. That cookie is then sent by the server to the browser that sent the request.

Next time, if the user tries to send another request to the server, then that request is sent to server with the session id, then server is able to process that request successfully.

Why a cookie needs to be created ?

Server needs to send the cookie to the browser in order to identify whether the request is coming from the same user or not. This happens, as HTTP requests are stateless in nature, that means each individual request is executed independently. Server has no idea about previous requests status, so it needs a way to keep track of the commands that were executed before; that's why to identify if the request is coming from the same user, it stores a unique session id in cookie.

So, every time the browser sends a request to a website it automatically attaches a cookie that is stored in the browser for that website. Even if the request to the website is made by another website that is loaded in the user's browser.

How Cross Site Request Forgery Actually Works?

Now, you've understood the basics behind sessions and cookies, let's discuss how csrf actually works.

The attacker creates a malicious website and then he or she uses social engineering tricks to lure the victim to visit that website. The trick could involve sending the victim an email stating that he or she won a lottery and claim the prize by clicking on a link.

When victim clicks that link, the script of that malicious gets executed and it can perform unwanted actions to the website in which he or she is currently authenticated. All of these incidents could happen without the knowledge of the user.

Example on cross site request forgery

To see CSRF in action, at first we need to create a new folder "hacker" under the root folder of our project directory. Also, we need to create some users manually in our users table. For example, I have created a user "dummyuser4". Then we need to create 3 files (e.g, config.php, index.php, delete_user.php) in hacker folder.

CSRF Config Page Codes

CSRF Index Page Codes

CSRF Delete Page Codes

We also made some changes in the dashboard page, the added codes for the dashboard page is shown below.

Dashboard Page CSRF Attack URL

Explanation of What We Did

In index.php page that is created inside hacker folder, the attacker uses jQuery library to initiate an Ajax call that will run the delete_user php script. After successfully executing the Ajax request, it displays 'success' message in the browser's console window.

The delete_user.php page get the name of the user from the current active session. Then it executes the delete query to delete that particular user from the users table.

We added an image in the dashboard page, that has a link attached to the index.php script file. So, when the victim will click on the image to claim his or her lottery prize, the CSRF would take place, in which the attack will delete a user named "dummyuser4".

Users Table Before CSRF Attack

Users Table After CSRF Attack

Preventing Cross Site Request Forgery Attack

Implementing Unique CSRF Token

The best way to prevent this attack is to use a unique token that will be auto generated by the server. The token must be generated in a random way and it should contain cryptographic value for each new request made to the server. The token should be stored in the user's session so that the server could be able to verify it.

Following youtube video explains this approach in depth.

Protecting Against XSS

If the web application is vulnerable to cross site scripting(link to my own article) (also known as xss), attack then the attacker can easily get the csrf token from the html page. So, in order to prevent csrf attack, we also need to make sure that no xss vulnerability exists in the web application.

Download the entire project by clicking below.

Final Words

If you find this post about Cross Site Request Forgery helpful, please share it among the others. Thank you!