How to find Stored XSS errors simply

This is how I found a Stored XSS (“Cross Site Scripting”) vulnerability in a program bug bounty and I will guide you in detail on how I found this error.

What is XSS?

XSS or Cross Site Scripting is a vulnerability in which a user could use a provided input field to insert an XSS payload. This leaves the user able to execute javascript on the site vulnerable, which can become very dangerous.

Here is an example of the XSS payload:

"><img src=x onload=alert(document.cookie)>

In the above example, we break out of the code structure with double quotes and a greater than sign at the beginning. Then we have full ability to execute our javascript since we have gone beyond the input field. For this example, we inserted an image with a random source of x and told the page to execute a warning containing the user’s cookie when the image was loaded.

Attackers will primarily use this method to steal other users’ cookies, thus allowing them to perform actions as if they were that user. They can also be used in many other types of attacks to affect companies or users.

Detect

For the privacy of the company, I will not disclose the name of the bug bounty program I am testing, but I will provide details on the path I took to find this vulnerability, this relatively easy in this case.

I started by scouring the target site and looking for potentially hacked input fields. While doing this, I found a function where you can upload images to post on your account page. This makes me think of a recent XSS bug report through image file content. But it failed.

I continue to experiment with the upload function and other inputs in the web application. While doing this, I looked up at the top menu of the input form and one thing that immediately caught my eye was a button that looked like <>. It usually means that you can edit the code used to show up in your post, I didn’t hesitate to open it up and see the code used for the photo I uploaded earlier. This shows that it is just plain html code consisting of an “img src=” as shown below.

I immediately knew what payload I wanted to test = “alert (1)”. We will have to put this command after the URL value and save it with the newly added payload. Below you will see the final code that looks like this.

These payloads are processed with the input and reflected into the HTML of the page. Although when I look at the payload, I can see it has been added to the “data-sanitized” value. Here is the page code:

When the page reloads, the JavaScript code is executed and a warning is displayed at the top of the screen, so I found the Stored XSS error.

Javascript will execute every time the page is opened, confirming that this is a Stored XSS error in the image code editor function.

Conclude

This has taught me how important it is to dig deep into each and every function of an app and not give up prematurely. If I had given up after the XSS failed to upload the image, I would never have been able to get around the image asset restrictions to find this vulnerability. This is a reason for you to keep digging into the app if you have a feeling that it might be buggy.