Challenge 7: XSS in a dropdown list
Learn how the XSS vulnerability can be found in other params even though it is not editable by the browser using the BurpSuite Proxy tool
Welcome back to learning Cross-Site Scripting(XSS) with the Kurukshetra series. An app built by d4rk36.
Before we start, ensure the lab is up and running, If you have not set up your lab yet. Feel free to refer back to the below link.
Raghunath G
XSS Vulnerable App - By Design
Recap
The previous article covered reflected cross-site scripting scenarios where poor input validation checks can be exploited further.
Also, it demonstrated the impact of missing input validation checks on the server side. Therefore the input validations must be implemented well on both the client & server sides.
Practicals
Post setting up the lab visit http://localhost:8066 and ensure it's accessible, then navigate to "XSS Challenge 7".
Coming to XSS Challenge 7, an input field is given to key in the text and a drop-down menu option needs to be selected before clicking on the "Submit" button.
Will try out all the things techniques learned so far about identifying the XSS vulnerability.
Payload Try 1: Classic
Output:
Using our classic payload, select the default option in the drop-down menu "India", then click on the "Submit" button.
Immediately, observe that the payload keyed in is displayed as it is. Right-click and select "View page source" to understand how the payload is being embedded in the HTML response.
Scrolling to the bottom of the page, I can see that our tags like '<', '>' etc.. have been replaced. This changes the meaning of the HTML format, and the browser considers it as text and displays it back without executing it as a script.
HTML Output Encoding
The above output that we are seeing is called HTML output encoding.
Output encoding is one of the mitigation techniques used to take user-controlled data and safely display it without interpreting it as code and considering it as text.
Below is an example XSS payload.
<script>alert(document.domain);</script>HTML-encoded text of the XSS payload will be displayed below.
<script>alert(document.domain);</script>- "<" changed to "<"
- ">" changed to ">"
As the browser parses HTML, JavaScript, CSS, and URL differently. Each must be encoded depending on the requirements.
URL, HTML, JavaScript, and CSS can be encoded.
The input text field in the application seems to be handled properly, but we need to find another way to exploit it.
XSS need not be present all the time in the input text fields, it can be found in other parameters as well which are parsed and used by the server.
Trying XSS in the "location" param
I will be using the "BurpSuite" proxy tool going ahead with the demo. Please make sure your browser is preconfigured with the BurpSuite and working as expected.
Visit the Challenge 7 page.
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.
Fill up the input field value with "Test XSS" and then click on the "Submit" button.
Now in the "BurpSuite" proxy tool, observe the request being transmitted to the server, is intercepted, and displayed as shown below.
Observe at the bottom of the request the "xss", "location" and "submit" params are being passed to the server.
Remember, in the previous article Challenge 6, we sent the modified XSS payload to the server.
In a similar way, this time in the "location" param value append our classic XSS payload, which will be displayed as shown below.
Next, toggle off the "Intercept is on" button to disable the request interception for now. Immediately switch back to the web browser.
Immediately observe that an XSS pop-up message will be displayed, as shown below.
YAY!! 🎉 by this, we can confirm the application is still vulnerable to the cross-site scripting vulnerability.
Click the "OK" button to continue, then right-click and select "View page source" to very our payload injection. Search for the payload inserted.
You can find the inserted payload at the bottom of the page. This time, you can see that our payload is displayed as given without any output encoding.
By this, we have successfully exploited the XSS challenge 7.
Summary
The key takeaway from this article is XSS need not necessarily be exploited from the user input form fields, the XSS vulnerability can be tested in any param header and value fields that are parsed by the server.
Keep learning! 😃