Challenge 9: XSS in the hidden input field

Welcome Back!! 😃

In today's article, let's check out how the XSS can also be exploited in hidden input parameter fields.

Before getting started, ensure your Kurukshetra lab is up and running. Feel free to refer back to the below link.

Practical Hands-On Way to Learn XSS with Kurukshetra

Kurukshetra is an intentionally designed XSS-vulnerable application. XSS explained with examples and an open-source lab for practicing cross-site scripting vulnerability.

SecurityArrayRaghunath G

The previous article covered how the limited character set can be leveraged to exploit the XSS vulnerability and why the single defense mechanism might not fully mitigate XSS vulnerability.

Practicals

Visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 9“.

The above page looks similar to the challenges we solved earlier.

Take some time and give it a try with all the XSS skills acquired so far before going any further.

As you guessed, I will go ahead and try out the classic XSS payload to verify how the application responds.

Payload Try 1: Classic

Output:

Input the XSS payload and click on the “Submit” button. Immediately, the application echoes out the output as given, and there are no pop-up messages this time.

This confirms that our payload didn’t work. Right-click and select "View page source" to understand how our payload is being reflected back in the HTML response.

HTML Page Source:

Referring to the above screenshot, an HTML input tag named "xss" accepts the value and echoes out at the bottom of the code after encoding the special chars.

You might be thinking from the previous article that we used the built-in "HTML attributes" to bypass the encoding and execute the XSS payload. The same logic can be applied here.

A big No. Why?

Challenge 8 – HTML Output:

Challenge 9 – HTML Output:

The major difference between XSS Challenge 8 and Challenge 9 is that in Challenge 8, the encoded output was injected inside the HTML input tag, while in Challenge 9, the encoded output is displayed outside of form HTML tags.

As shown in the above challenge 9 screenshots, even though the HTML attributes can be injected, as they fall outside the HTML tags, the web browser would just consider it as text without any special flags.

Therefore, the XSS payload will not work here.

Yes, the XSS need not always need to be exploited in the same param value location, it could be checked on the other supporting param which may use the same value for processing. Also, it can be located in param values where input values are appended or depended on.

Challenge 9 – HTML source Output

Paying a bit more attention to our Challenge 9 HTML response, we can see there is another HTML input tag used of type "hidden".

In HTML, the hidden input type stores pieces of user data without displaying it to the user on the frontend. Web browsers generally hide it, and you can find this data by viewing page sources or by using intercepting proxies like BurpSuite or OWASP ZAP.

Let’s go ahead and try the XSS payloads in the hidden fields.

It can be done in multiple ways, as covered in previous articles, such as using a browser debugger or using intercepting proxies. I will be using the BurpSuite proxy for usability.

Execution Steps

1. Configure and Launch the Burpsuite tool.
2. Navigate to the "XSS Challenge 9" page.
3. Enable the BurpSuite interception proxy to intercept the request before it is sent to the server. To do that, Navigate to BurpSuite "Proxy" -> "Intercept" -> Toggle the "Intercept is off" button to enable "Intercept on".
4. On the Challenge 9 page, key in the random input value(say "Test XSS") and click on the "submit" button.
5. The intercepted request will be displayed as shown below:

6. Observe that in line 22, the input param and its values are being passed in the request body section.

7. Replace the "hidden" param value from "Is that it" with classic XSS payload.

The modified request will be displayed below.

8. Toggle off the “Intercept is on” button to disable the request interceptions for now and forward the modified request to the server. Then, switch back to the web browser.

9. Immediately observe an XSS pop-up message, which will be displayed as shown below. then click on the “OK” button.

10. Wow!! It worked out, and we were able to successfully exploit XSS challenge 9. 😄

Lastly, always verify the HTML response code. Right-click and select "View page source" to verify how the injected XSS payload is appended.

I can confirm that the injected XSS payload in the hidden parameter value field has been passed to the server and reflected back in the response without any encodings this time.

Hence, our payload was executed. ☺️

Summary

In this article, we’ve seen how other parameters can be utilized to exploit XSS – it doesn’t always have to be done within the same param field.