Continuing on from Part 1 XSS: Intro, we will go over how we enumerate XSS. The way we go about enumerating XSS is first to properly map the application and understand its inputs. This is done via browsing/spidering, and unlinked content enumeration using various techniques. To browse and spider the application we use Burp suite and click through all the links on the application then leverage Burp Suites spider. To spider an application in Burp you can add the target URL to your scope and right-click the target on the site map and choose “Spider this host”:
One way that we gather an overall snapshot of a target URL in more detail is through Burp Suites engagement “Target analyzer” feature. This feature can present not only a snapshot of quantifiable data on dynamic vs static content, but also a more detailed view as to what URL’s fall into each categories as well the parameters that we can tamper with.
To enumerate unlinked content we leverage several different techniques:
- Check for common resources using a word list
- Probe the application for known resources based on the technology stack
- Leverage Burp’s Engagement tool > Discover Content
Check for common resources using a word list:
We really like SecList a project by Daniel Miessler, and Jhaddix. (Side Note: Daniel Miessler just started a new project called “RobotsDisallowed” – this is a collection of disallowed resources from top sites robots.txt) SecLists is a collection of wordlists, fuzz lists, usernames, passwords, etc. for security testing. For purposes of unlinked content enumeration we really like the raft lists that are included in the SecList project. You can combine this with Burp’s Intruder to enumerate unlinked content in an automated fashion.
Right-click a request to the target application and click “Send to Intruder”:
Now click on the “Positions” tab and clear out all the payload markers. Then define the location in the request you’d like to have Intruder fuzz:
Next navigate to the “Payloads” tab and choose your desired wordlist, in the example below we are leveraging the “raft-large-files.txt” which contains ~37 thousand entries (I normally uncheck the Payload Encoding option for this type of intruder session):
Finally choose “Start Attack”. You may want to define a grep search or sort by the HTTP status code so you can pull out interesting results. In situations where the application responds with a custom 404 page via an HTTP 200 OK, you may want to define a grep search string of “404 Item not found” and then sort by entries that do not have that string in the response.
Note: This very same process can and should be followed with parameter enumeration. In black box testing all the application parameters may not be linked, you might have unlinked parameters such as, redirect=, download=, file=, upload=, etc.
Probe the application for known resources based on the technology stack:
In addition to the fully brute force method of enumerating content, we suggest also more intelligently guessing for resources based on the technology stack. For example if the application is a Joomla application
Leverage Burp’s Engagement tool > Discover Content:
We also suggest using Burp’s engagement functionality. This feature can be useful because Burp will attempt to enumerate unlinked content using several different techniques, including dynamically creating requests based on names observed in use on the target site:
Escaping Out of Parameter Values
When enumerating XSS you might see your input land in HTML that you might need to first break out of the HTML tag. The most common ways to break out of the current HTML tag is to append (“>’>[XSS_Payload]). You need to view response in your proxy or view source in your browser and see where your input is landing on the page. You may need to close out of a different HTML tag before you can place in your XSS payload.
Below is a very trivial example of this to illustrate the concept. The user’s input is taken from the “page” parameter and dynamically added to the page in an href tag. So if a user places the XSS payload directly as the parameter value it will fail to execute:
Inspecting the HTML source you might notice that our input is being included between (href=”[user_input]”>), so to escape out of this we need to add a “> to our XSS payload:
Using Intruder to test for XSS
Using the same logic as earlier when attempting to enumerate resources, we can apply it to parameter fuzzing in an attempt to enumerate XSS vulnerabilities. SecLists (linked above) also maintains an XSS specific fuzz list (SecLists > Fuzzing > JHADDIX_XSS.txt) which can be used to attempt a variety of standard and polyglot payloads to identify vulnerabilities.
Note: A Polyglot payload is one that utilizes multiple contexts to execute. For example “onclick=alert(1)//<button ‘ onclick=alert(1)//>*/alert(1)//
To demonstrate, we will start by loading up a request in Intruder. We will be making a request to a resource containing a vulnerable parameter:
We can now load the ‘JHADDIX_XSS.txt’ file as our wordlist to apply to the potentially vulnerable, and then start the attack:
The application may respond in numerous ways, such as returning 500 error codes for invalid parameter input, or just generic 200 responses. We need to keep an eye out for a valid response that displays some or all of our input on the page:
One last caveat is that as you’re enumerating XSS keep in mind that it could also be another vulnerability entirely. Something that allows for XSS could also be Remote File Inclusion (RFI)/Local File Inclusion (LFI) that can lead to Remote Command Execution (RCE). An example is the screen shot below, in a future blog post we will demonstrate how this is more than just XSS: