What Is XSS?

Let us start this section with a diagram (Figure 4-1).

In Figure 4-1 we see that there are two interfaces: one is the user’s interface and the other is the hacker’s interface. The user clicks a link that contains malicious JavaScript code. How did the user get this link? Either it had been sent in an e-mail by the hacker or the attacker had posted it in a public forum; the link had been disguised as “Read More” or something like that. Once the user clicks the link, they become a victim. Figure 4-2 showcases this scenario in detail.

The JavaScript code works on the browser. So it targets a particular user who has clicked the link. Clicking the link enables the user’s browser to implement the malicious JavaScript code on it, which in turn takes out the user’s session cookie. Once the attacker gets the user’s session cookie, the mission is successful. Using the same session cookie, the attacker transfers the user’s money. Therefore, Figure 4-2 represents reflected cross-site scripting . The malicious code is stored in a link to be clicked, rather than as part of a web site itself.

Stored or persistent cross-site scripting is a little bit different. It generally takes place when user input is stored on the target server, such as in a database. That data is in the form of malicious code that is rendered on the browser without being made safe. For example, the attacking code is stored in posts by the attacker in a forum. As other visitors visit the forum they become the victims of XSS attack, because the code is executed every time the forum post is viewed in a browser.

In the next section, we will see how we can discover any XSS attack.

Discovering XSS Vulnerabilities

Discovering any XSS attack in a web application has been made easy through Burp Suite. We can easily discover whether a web application has vulnerabilities or not. We can also discover whether it has already been attacked by someone or not just by attacking it using Burp Suite.

To do this test, we will install OWASP Broken Web Application or owaspbwa . It is a collection of many intentionally vulnerable web applications that consists of WebGoat, DVWA, Mutillidae, and many more. We have seen and tested some of them. However, we can get all of them in one place. Although it has not been updated for a while, there is no alternative where you have many intentionally vulnerable applications under one roof. Of course, you can install each one individually and install the recent version; however, that would take time. In fact, in my opinion, that is not important. These are all playgrounds where you can examine a concept and try to understand the repercussions. Therefore, you can install it and examine different types of security bugs.

The installation part is not difficult. Download and install it on your VirtualBox so that whenever you want to test your hacking skill you can practice on it locally (Figure 4-3).

First, download the OWASP Broken Apps VMDK files. All five files will be downloaded but it will take some time, as it is around 4 GB.

Next, open your VirtualBox and just install it like any Linux operating system. Memory size 512 MB is perfectly fine. While you are choosing the path, point it out to the VMDK file and it will get installed. In the network section, choose the bridge adapter so that, keeping your Internet connection on, you can connect it to your Burp Suite or OWASP ZAP.

Usually, the URL varies between 192.168.2.2 and 192.168.2.3; it will be shown when you start it in your virtual lab. Log in is root and the password is owaspbwa.

Locally, it is running on http://192.168.2.3:3000; before launching this application, we need to keep our Burp Suit’s intercept in “off” mode to let the traffic pass through Burp.

As I have said, there are many applications inside it; I have chosen the bWAPP application (Figure 4-4).

We will create a new user here. We would like to see the reflected traffic on our Burp Suite. In the Burp we have got this output:

We can clearly see that the new user’s e-mail is [email protected]; the password is foo1234; and the answer to the secret question is “my secret” (Figure 4-5).

We can exploit this user-name and password in the future, but before that, we will test whether this bWAPP application has vulnerabilities or not.

We can try to inject some JavaScript code inside the user-name input filed. Let us see the result.

We have injected this code into the input field (Figure 4-6).

We have found that it is working perfectly. Here is the output on the browser (Figure 4-7).

In the response section of Burp Suite, we have received this message:

Next, we will test another web application called Vicnum; here you can guess a number and play a game. We have selected the Guessnum project (Figure 4-8).

In our Burp Suite we have included this web application into the “Intruder” section and loaded a bunch of JavaScript code. You can get plenty of JavaScript code in the seclist GitHub repository. Just search inside GitHub and download the zipped folder.

https://github.com/danielmiessler/SecLists,

Here you can have a collection of multiple types of lists that are used during security assessments, collected in one place. List types include usernames, passwords, URLs, sensitive data patterns, fuzzing payloads, web shells, and many more.

Let us start an attack and click “show response in browser”; it will give us a URL (Figure 4-9).

We are going to paste this URL on the browser and see whether that opens up the attacked application or not. If it opens up, it will be a proof of concept that this web application has plenty of vulnerabilities; and an attacker can benefit from it. Sometimes, if username-password combinations mismatch or the JavaScript code does not work, the browser may not open the page. Don’t get frustrated; it’s a trial and error method, and you need to try different types of files downloaded from the GitHub seclists resource. My efforts have not yielded any result in the first attempt!

I want to emphasize one thing: patience is the key if you want to become a successful penetration tester or bug bounty hunter. Most of our jobs are based on this trial and error method.

At the same time, we will scan the same application with OWASP ZAP. ZAP’s scanner is extremely good and it will give us three types of alerts: high, medium, and low. These alerts are marked by three colored flags. Red flag means high, orange flag stands for medium, and low is flanked by a yellow flag. We have got seven high alerts in this web application (Figure 4-10).

I highly recommend using Burp Suite and OWASP ZAP side by side. Sometimes it is not necessary, because Burp Community edition alone can handle the task. However, in some cases we can double-check with the ZAP scanner.

We can get the ZAP scanning report at the same time by pressing the Active Scan on the top (Figure 4-11).

This scanning report gives us a detailed view of how we can avoid vulnerabilities; as a penetration tester, you can advise your client to take necessary actions based on that.

The number of alerts may differ from time to time, depending on a few things. The JavaScript code you have used for your attacks may vary; the vulnerabilities of the application may also vary. Last, which type of alert you have selected to get the scan report also matters.

I have included a part of this scanning report here:

The advantage of using ZAP is that you can have an idea of how to write your report. As you see (code 4.4), the solution has also been given.

In OWASP broken web applications there are plenty of different intentionally vulnerable applications. But you can’t just use any of them for any type of attack. The last application (Vicnum) is not suitable to exploit using the brute force method for stealing username-password. Therefore, we need to try another application, which will give us an overview of how we could do that type of XSS attack.

Exploiting XSS Vulnerabilities

In this section, we will see how we can exploit through XSS. We want to adopt the brute force method to steal the user-name and password of any application.

Let us try the Damn Vulnerable Web Application or DVWA (Figure 4-12). You can install it individually and open it; or you can open it from just installed OWASP BWA collections.

We have already opened our Burp Suite and kept the intercept in “off” mode, so that the DVWA application could have opened and the traffic could pass through Burp.

In the next step, we will change the Burp intercept mode to “on” and will try a user-name and password combination on the DVWA.

Let us try a simple user-name and password combination, such as “user” and “password.” You can try any combination. Whatever combination you use, it should reflect on the Burp like this (Figure 4-13).

You can see the output here:

At the last line, you can see that the user-name and password combination has been reflected.

Next, we are going to select the last line: username=user&password=password&Login=Login and click the second mouse button. Several options are opened up; we will select the option to send it to the Intruder. Once it has been sent to the Intruder, click the Positions tab at the top of the page; you will find that a few lines have automatically been selected. On the right side, you will find some buttons: Add, Clear, etc. (Figure 4-14)

We will click the Clear button and clear those selected lines. Next, we will select user-name, password, and the login in the last line and click the Add button. Basically, the Clear button removes all types of special characters from the whole response. When we use the Add button, we add the payloads where we need them. For each attack request, Burp Suite takes the request template and places one or more payloads into the positions. We have chosen the Sniper attack because this uses a single set of payloads.

Now our payloads are ready, so we can mouse click the Payloads tab at the top of this window. Now we can add some user-name here, such as “admin,” “john,” “smith,” etc. (Figure 4-15).

For the passwords, we will load a default word list from usr/share/wordlist, from the metaspoilt folder, which includes many files with “.txt” extensions like this (Figure 4-16).

Once it has been done, click the “Start attack” button on the top right-hand corner (Figure 4-17). The XSS attack will take place once you click the button. The username-password payloads will start checking all the combinations used in the DVWA application.

It will find the combination of user-name and password individually; therefore, it may take time according to the number of user-names and passwords that have been fed to the Burp Suite.

In a normal case, on the right side, you can watch the Length of the status. The top one is considered to be the base, where we can expect the XSS attack to successfully exploit the vulnerability of the application and find the right combination.

Here it is 1777; this number is calculated by Burp Suite based on probability. Hence, the higher the number, the greater the chance of success.

We have finally got a combination that matches 5218, which is much greater than 1777. The combination is admin and admin.

Let us try this combination on DVWA.

It works absolutely fine; we can safely enter the application by typing user-name admin and password admin (Figure 4-18).

Once we have logged in, the Burp Suite catches the traffic again:

Watch the last line: our user-name and the password combination have been reflected in the output.

Through advanced XSS attacks, hackers can also implant malicious code in web sites. As I mentioned earlier, broadly there are two types of XSS attacks; in one of them, data is included in the dynamic content. Because of that, every now and then, we hear about a new type of attack. Megacart attack is one of the latest attacks where many banks in the United States and Canada were affected. In such attacks, using client-side browsers, data were skimmed.

Therefore, keep yourself always updated; read articles pertinent to the discussion. Furthermore, finding security bugs in any web application is not limited to one single concept like XSS. There are other types of attacks, and they are related. In the coming chapters we will learn them. As you learn different techniques, my recommendation is always try to find what connects the dots. How is one type of vulnerability related to another type of vulnerability?