XSS in JavaScript strings 1

In this module, we will exploit the XSS vulnerability in the exercise target, so you can start the task below and follow the steps at your own pace.

XSS vulnerabilities can often occur if user-controlled input is processed or used insecurely in the application's own JavaScript code. When testing web applications, it is important to understand and ensure the functioning of the JavaScript code on the client side.

Finding Vulnerability

We begin by examining the functionalities in the application and quickly notice that the application uses the values entered in the search field as a string of JavaScript code.

The value of the search field is reflected in the search parameter and in the application's JavaScript code, in a string named searchTerm.

We continue the analysis by looking at how the application handles special characters. Our intention is to try to break the structure of the string so that we can write our own JavaScript code after the string. We try the following input.

'; const own parameter='

We can use the search parameter used directly in the URL address for this.

We were able to define our own parameter within existing code. This means that we can write our own JavaScript code using the search parameter. The application is vulnerable to XSS attacks.

We notice that the application does not properly format or prevent apostrophes, which allows for string escaping and adding own JavaScript code within the existing code.

We also verify whether the application accepts the use of special characters used in HTML code with the following input.

';</script>

Note that the application formats the entered < and > characters correctly, so the returned text in the browser contains the HTML-encoded versions of the characters.

The application seems to prevent special characters typically used in XSS vulnerabilities, so we will have to use the first method we find to perform an XSS attack. It is also a good practice to double-check the vulnerability by triggering an alert box in the browser.

In JavaScript code, the // character combination is used for commenting, which comments out the input below from the rest of the code on the same line. This is not mandatory, but it makes building the final malicious code easier.

'; alert('xss'); //

Note how the // marks comment out the rest of the code, so we don't have to worry about possible errors that could arise from our input.

Exploit Vulnerability

Finally, we perform an attack using the same idea as in the first module, which is using the application's built-in link storage function to leak the system administrator session cookie. This happens in the following steps.

• We save the new link ourselves and analyze the resulting HTTP request
• We repeat the request with JavaScript code, so that the saved link contains session cookies. (document.cookie)
• We encode our malicious code in a way that it functions in the discovered XSS vulnerability
• We add a link to the page that contains the final URL where our malware is located. Here we use the search parameter.
• We expect the system administrator to test our link that forces the system administrator's browser to create a new link itself, including their session cookies.
• We log in as an administrator

Try to replicate the listed steps yourself! - You can take inspiration from previous modules.