Challenge 8: XSS bypass improper output encoding
Learn how the partially implemented HTML output encoding can be bypassed for exploiting XSS vulnerability using the HTML5 attributes
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
Practicals
Hope by now you are familiar with what an XSS is and how it can be identified. In this article, you will be learning about how to exploit XSS when limited characters are allowed.
Post setting up the lab visit http://localhost:8066 and ensure it's accessible, then navigate to "XSS Challenge 8".
From the above screenshot, I can see that the application is requesting the input value in the "Try Your XSS payload?" field.
Feel free to try and experiment with different payloads.
Initially, I will go ahead and try out our classic XSS payload, which has been used throughout our series.
Payload Try 1: Classic
Output:
After keying in the payload value and clicking on the "Submit" button. Looks like nothing happened.
No pop-ups and no partial or filtered messages. Interesting!
Let's go ahead and view the HTML source code received from the server to understand what is happening in the background.
Right-click and select "View page source", then search for the injected payload string.
From the above screenshot, it could be understood that output encoding has been applied to injected XSS payload which prevents execution of the script tag.
Try out and verify all the XSS payloads which have been discussed throughout the series. Using IMG tag XSS, SVG tag-based XSS, etc.
As the heading says, you can keep on trying out any number of HTML tags and verify which XSS payload works. Or another better option could be to find out the list of allowed characters with multiple trials and errors and craft one using the allowed list of characters.
Identifying Allowed Characters
Using previous XSS payload output can confirm the javascript alert() function is allowed, next single quotes "'" are allowed, "/" slash is allowed, and lastly alphabets are allowed too.
Now need to find out, how the allowed list of characters can be used and make the XSS payload work.
Remember the XSS payload used in "Challenge 4", Using HTML5 Attribute.
In the above XSS payload, can see that most of the characters are allowed, but we haven't verified double quotes "".
Quickly will go ahead and verify if the double quotes are allowed in the input field. By injecting and viewing the page source code.
Output 2:
Now, can confirm that double quotes are also allowed as injected without any encoding or escaping. Nice!
Let's understand the XSS payload before trying it out.
Our motto is to rightly align the XSS payload in HTML response code and make it executable.
All the injected payload characters are inserted within the HTML input tag within the value field.
If the input is keyed in like onmouseover=alert('xss') without quotes, it would be treated as text, and all the HTML attributes will not be of much help here. For the same reason, we use the extra quotes to properly align inside the input value field.
- A double quote for closing the value section
- onmouseover is one of the HTML attributes that can be used with HTML tags. The moment the mouse hovers over the code, the given javascript alert() function gets triggered.
- Another double quote to make sure the remaining double quote of the value field is aligned with HTML syntax.
Enter the above-improvised payload in the input field and click on the "Submit" button.
Output 3:
For a moment, things seemed like nothing had happened, and the application behaved normally as expected. As seen before.
Hover over your mouse onto the input field and observe, immediately a pop-up message is prompted as shown below.
Waah!! 🎉 Our XSS payload worked. Let's verify the HTML response code to confirm how the XSS payload is aligned further.
Right-click on the "View page source" and search for the injected XSS payload string.
The given payload got rightly aligned and only the allowed list of characters and HTML attributes have been used to exploit it.
We have successfully solved the XSS challenge 8.
Summary
This post demonstrates how generally output encoding is used to prevent XSS, but that itself is not enough to prevent the XSS vulnerability. The input HTML attributes and allowed characters can be carefully used to craft a working payload. To prevent the XSS vulnerability a Defense-In-Depth approach needs to be leveraged. Like performing output encoding, sanitizing, using CSP, etc. Which would be covered later.
Keep learning! 😃