In this module, we exploit the XSS vulnerability in the exercise target, so you can start the task below and repeat the steps at your own pace. The task uses the BurpSuite tool.

Steal the administrator session cookies and authenticate to the system as that user.

In this task, we take advantage of an XSS vulnerability and steal the administrator's session.

XSS 1


XSS vulnerabilities can be found practically anywhere, where the application allows the user to input something that the application will return back to the browser at some point. The first step in searching for such vulnerability is to send an input to the application and search the HTML code for a place where the input is reflected.

Let's start by sending a message to the chat and finding it in the HTML response.

You can, for example, use the search field provided by BurpSuite when searching for your message from the HTML code.


Next, HTML-formatted input will be sent to the application. If the application is not vulnerable, it will convert HTML characters such as 

. However, if the application is vulnerable, the characters will remain as is in the HTML response, giving you the opportunity to make arbitrary modifications to the application's HTML code.

 and find that the application is vulnerable. Note that the input is URL-encoded.


This allows us to conclude that this website is vulnerable. Next, we will attempt to exploit this vulnerability and steal the main user's session cookies.

First, let's ensure that we can input JavaScript code into the page using the traditional 

 element. For example, in security audits, a common Proof of Concept (PoC) is to display a JavaScript alert as follows:

When you see the alert box on the page, you have verified the vulnerability as well as your ability to use JavaScript code in an attack. Next, let's see how the vulnerability can be exploited.

If the application uses cookies to manage sessions and has not protected the cookie with the 

 directive (which prevents JavaScript code from accessing the cookie), the session ID can be read through the 

Try it! Do you see your own session ID in the pop-up?

Stealing System Administrator Session Identifiers

Next, we will steal the administrator's session token by sending JavaScript code to the application that leaks session tokens through the chat function. When the administrator sees the message, our JavaScript code is executed and the tokens are automatically sent to us.

We carry out the attack in the following steps:

We send a message to the application and analyze the resulting HTTP message.

We are writing JavaScript code that sends a message automatically and will test it first against ourselves using browser developer tools.

We inject the same code into the page by exploiting an XSS vulnerability and wait for the administrator to visit the page.

We read the administrator session cookie from a forced message, set the cookie for ourselves, and confirm the success of the attack.

Sending a new message and checking the inquiry from BurpSuite HTTP history. We will be noting the following things.


Below is the structure of the HTTP request triggered by the new message.

Step 2: Writing the JavaScript code used in the attack

Next, we want to write a JavaScript code that performs a similar HTTP request as what we analyzed earlier. The JavaScript language has multiple different ways to execute an HTTP request, but in this example, we use the 

JavaScript code that sends cookies through the chat function, as a new message.

On the first line, we create a new FormData object and save it in a variable called 

. Here, we add our HTTP request parameters, which is 

On the second line, we add the HTTP body parameter 

 function and give it first the path, which is 

, and finally the HTTP body, which is already prepared in the 

Let's try to execute the code with browser development tools. Make sure it works:

Checking the BurpSuite HTTP history to verify that the message originates.

Updating the page and ensuring that session identifiers are sent as new messages to the website.

Next, we will execute an attack. We insert the attack code into a 

 tag and send it to the page with a message.

We expect the administrator to revisit the page, at which point the administrator should send their session identifier via message

Note that you are also sending your own session identifiers every time you reload the page, because you are exposed to attacks just like the system administrator.

Step 4: Adding the stolen session token to your own browser

 window and add an administrator cookie to the browser. The easiest way to do this is to open the JavaScript console and set the administrator cookie yourself.

Finally, we update the page and verify that we are logged in as an administrator.

*In this module, we exploit the XSS vulnerability in the exercise target, so you can start the task below and repeat the steps at your own pace. The task uses the BurpSuite tool.*

@exercise 75444c1ee62f

XSS vulnerabilities can be found practically anywhere, where the application allows the user to input something that the application will return back to the browser at some point. The first step in searching for such vulnerability is to send an input to the application and search the HTML code for a place where the input is reflected.

Let's start by sending a message to the chat and finding it in the HTML response.

![](sanity:image-51e3974ae8e1cb606b144ec9f8abbba0ac07d5d8-1661x840-png)

*You can, for example, use the search field provided by BurpSuite when searching for your message from the HTML code.*

![](sanity:image-f83e78dde02db940b0d104749e975b00718ddca9-1935x1082-png)

Next, HTML-formatted input will be sent to the application. If the application is not vulnerable, it will convert HTML characters such as **<** and **>** into a secure format **&lt;** and **&gt;**. However, if the application is vulnerable, the characters will remain as is in the HTML response, giving you the opportunity to make arbitrary modifications to the application's HTML code.

*In the image below, we enter ****<b>hello</b>**** and find that the application is vulnerable. Note that the input is URL-encoded.*

![](sanity:image-2530e2b5625126a1b8a2f0c82b40f713015f5b5a-1935x951-png)

![](sanity:image-2ff6ddc91a08bfc9e3d4af305e524827ea1a8f09-1703x496-png)

This allows us to conclude that this website is vulnerable. Next, we will attempt to exploit this vulnerability and steal the main user's session cookies.

## Adding JavaScript code to the page

First, let's ensure that we can input JavaScript code into the page using the traditional **<script>** element. For example, in security audits, a common Proof of Concept (PoC) is to display a JavaScript alert as follows:

```html
<script>alert(1)</script>
```

When you see the alert box on the page, you have verified the vulnerability as well as your ability to use JavaScript code in an attack. Next, let's see how the vulnerability can be exploited.

---

## Reading Session Token

If the application uses cookies to manage sessions and has not protected the cookie with the **HttpOnly** directive (which prevents JavaScript code from accessing the cookie), the session ID can be read through the **document.cookie** property as follows:

```html
<script>alert(document.cookie)</script>
```

Try it! Do you see your own session ID in the pop-up?

---

## Stealing System Administrator Session Identifiers

Next, we will steal the administrator's session token by sending JavaScript code to the application that leaks session tokens through the chat function. When the administrator sees the message, our JavaScript code is executed and the tokens are automatically sent to us.

We carry out the attack in the following steps:

- We send a message to the application and analyze the resulting HTTP message.
- We are writing JavaScript code that sends a message automatically and will test it first against ourselves using browser developer tools.
- We inject the same code into the page by exploiting an XSS vulnerability and wait for the administrator to visit the page.
- We read the administrator session cookie from a forced message, set the cookie for ourselves, and confirm the success of the attack.

### Step 1: Message Analysis

Sending a new message and checking the inquiry from BurpSuite HTTP history. We will be noting the following things.

- HTTP method: POST
- Request path: /
- HTTP body parameters: message

*Below is the structure of the HTTP request triggered by the new message.*

@embed 2b34b0b188ae

### Step 2: Writing the JavaScript code used in the attack

Next, we want to write a JavaScript code that performs a similar HTTP request as what we analyzed earlier. The JavaScript language has multiple different ways to execute an HTTP request, but in this example, we use the **fetch **function.

*JavaScript code that sends cookies through the chat function, as a new message.*

```javascript
var fdata=new FormData();
fdata.append("message", document.cookie);
fetch("/", {method: 'POST', body: fdata});
```

The above code works as follows:

- On the first line, we create a new FormData object and save it in a variable called **fdata**. Here, we add our HTTP request parameters, which is **message**.
- On the second line, we add the HTTP body parameter **message** and set its value as **document.cookie**, which contains the user's cookies.
- On the third line, we call the **fetch** function and give it first the path, which is **/**, then the method, which is **POST**, and finally the HTTP body, which is already prepared in the **fdata** variable.

Let's try to execute the code with browser development tools. Make sure it works:

- Checking the BurpSuite HTTP history to verify that the message originates.
- Updating the page and ensuring that session identifiers are sent as new messages to the website.

### Step 3: Attack

Next, we will execute an attack. We insert the attack code into a **script** tag and send it to the page with a message.

```javascript
<script>var fdata=new FormData();fdata.append("message", document.cookie);fetch("/", {method: 'POST', body: fdata});</script>
```

We expect the administrator to revisit the page, at which point the administrator should send their session identifier via message

*Note that you are also sending your own session identifiers every time you reload the page, because you are exposed to attacks just like the system administrator.*

### Step 4: Adding the stolen session token to your own browser

We open a new *incognito* window and add an administrator cookie to the browser. The easiest way to do this is to open the JavaScript console and set the administrator cookie yourself.

```javascript
document.cookie = "SessionId=.eJ...";
```

Finally, we update the page and verify that we are logged in as an administrator.


Stored XSS and stealing session cookies

Learn how to find and exploit a vulnerability that is one of the most common vulnerabilities, easy to find, and yet very dangerous. Hackerone ranked XSS the #1 bug bounty vulnerability of 2021.

XSS (Cross-Site Scripting) vulnerabilities are both common and serious. For example, HackerOne has listed XSS as the number one vulnerability on their top 10 vulnerabilities list.

Vulnerability management is therefore extremely important, whether you are a penetration tester, a security consultant, a developer, or a bounty hunter!

Stored XSS and stealing session cookies

Adding JavaScript code to the page

Learn to hack — start here