Cross-Site Request Forgery (CSRF) Vulnerability – Types, Mitigation and Exploit

[nick]

Hey Folks, today we are going to talk about an amazing vulnerability that is often found in web applications known as “Cross Site Request Forgery (CSRF)“. In this tutorial we will discuss all the concepts and possible attacks that can be executed during the availability of this vulnerability in a web application.

Let’s take a look !!

CSRF Vulnerability ( Introduction )

CSRF stands for the Cross Site Request Forgery, an attacker forces the end user to take unwanted action on a web application that is not intended to be done. For instance : A web application is vulnerable to the CSRF vulnerability and user is active on their account, during this an attacker can force the end user to perform unwanted action by sending malicious HTML documents through social engineering techniques and as soon as the user clicks on the document, the action will be completed without his / her knowledge. The action may be :

• Transferring Funds
• Changing their Email Address
• Money Transfer
• Change Passwords
• Change Secrets

CSRF attacks are also known by some other names, including XSRF, “Sea surf”, session riding, cross-site reference forgery, and hostile linking. We have also given a short description of this vulnerability via image, through which you will get a complete idea about this vulnerability. Let’s move on to exploitation.

We are using bWAPP vulnerable web application which you can setup for practice purposes from here in your localhost machine.

Change Password via CSRF

I think you are familiar from this features as it most commonly often found in web application but usually such a feature only occasionally makes web applications vulnerable. How it’s possible let’s see !! Look at the image below, where two inputs are given to change the password of the current user “bee“. But we will consider this feature as an attacker and try to do some manipulation. We click on change button after entering the new passwords.

You have to prepare yourself in advance with the Burpsuite tool. After click on “change” button the HTTP request will be appear on the burpsuite as like below. But there are two important things that testify that a web application is vulnerable to CSRF. The first thing is that the web application uses “GET” methods to send sensitive data to the server and the second thing is that the web application take the user’s input and execute it directly instead of taking cookies or any specific identity such as CSRF token.

Now it’s proof that the web application is vulnerable to the CSRF vulnerability. Now as an attacker we have to ready an CSRF PoC through the features of this tool.

We do not need to replace any value. It’s is an CSRF PoC that will automatically change the password of current user by clicking on it.

Now we will save it as .HTML documents and also can change the password from here at the last moment.

The interface will look like below when the victim opens this file on their browser.

Boom !! As you can see that the password changed as soon as the victim clicks on the “Submit Request” button. Thus, attackers acquire accounts through CSRF vulnerabilities with knowledge of social engineering.

Mitigation

As you can see the developers add an additional “current password” features, due to which the attacker can no longer perform a CSRF attack as it is mandatory to enter the user’s previous password.

Transfer Amount via CSRF

Let us take a different scenario, in this attempt we will try to transfer funds from this to someone else’s account through due to CSRF vulnerability. Now first we will check the process of web application by sending some money to this account.

Ok !! Transfer processing works perfectly because you can see that now we have only “890” Euros left after transferring “100” to this account.

Now we will intercept the HTTP request by finger pointing we means by burpsuite tool.

Again we’ll go the “Generate CSRF PoC” and copy it.

Create a “.HTML” extension file on the desktop and paste the entire code that we copied from burpsuite.

It’s time to do some manipulation and we will replace the original account details with another account.

Victim !! Thus the malicious document will appear on the browser after opening by the victim. Logic is very simple !! If the victim has logged into their bank account and they also click on that document incidentally, then what will happen is the result you can see yourself further.

Nice !! Money is lost ! as you can see the money has been successfully transferred to another account without the knowledge of the victim after clicking on the malicious document.

Mitigation

Attacker can perform a CSRF attack if he know that which value are being used in a form. Therefore a new token and any unique identification should be generated on every request of the client.

Change Secret (CSRF)

Different types of attacks may be possible if the site is vulnerable to CSRF vulnerabilities and is also one of them. In this effort we will explain how attackers take advantage of CSRF vulnerabilities to change users’ secret keys.

Re-boot your burpsuite tool again and intercept the request. Examine the highlighted text that should be present on the burpsuite.

Click on action button, select “Engagement tool” otpion and click on “generate CSRF PoC” and you will reach the following location. Just copy the content.

Create a .HTML extension file with your favorite tool and paste it on there. At the end you can change the secret key that you want to change by the victim.

As soon as the victim clicks on the sent malicious document, he will get the submit button on the browser.

Done The secret value changes automatically as soon as the victim clicks the submit button. Thus, the attacker predicts such an attack by having a CSRF vulnerability.

Mitigation

Again the attacker has taken advantage of this by not having any CSRF tokens in HTTP request-response challenges. Therefore the CSRF token must be invoked and also terminated after use.

Impact of CSRF Vulnerability

Now we’ll discuss with you over an live example. The Multi-Scheduler plugin 1.0.0 for WordPress has a Cross-Site Request Forgery (CSRF) vulnerability and in the forms it presents, allowing the possibility of deleting records (users) when an ID is known. You can also download it for practice purpose here.

As we told you that it allowing an attacker to delete the records (users) when an ID is known. Hence we we’ll create an new professional by click on there.

Now to get an idea about the record created we will click the delete button and intercept the request.

We arrive directly at the following location to consider the value of the first professional we created. We check that the professional that we made is value 1 and as we make it, it will grow progressively like :1,2,3,4,5,etc.

Just copy on there and paste it on “.HTML” file. We think the attacker can delete any record by changing the numeric value in the form. Let’s see what happen ? !!

Ready !! In a way the victim is ready to click on the submit button.

Boom !! OMG ! you can see that the record is deleted as soon as the victim clicks the submit button in their naivete. Thus, such unsafe plugins may be present in your web application, so if you want to avoid such attacks then you have to update all the plugins.

Credit : owasp.org and wikipedia

About the AuthorShubham Goyal Certified Ethical Hacker, information security analyst, penetration tester and researcher. Can be Contact on Linkedin.