For the purposes of detecting XSS, Direct or Plain HTML refers to any aspect of the HTML response that is not a tag attribute or scriptable context. This article will demonstrate how to identify reflections of user input, and inject an XSS attack in to such a context.
The example uses a version of "Mutillidae" taken from OWASP's Broken Web Application Project. Find out how to download, install and use this project.
First, ensure that Burp is correctly configured with your browser.
With intercept turned off in the Proxy "Intercept" tab, visit the web application you are testing in your browser.
Visit the page of the website you wish to test for XSS vulnerabilities.
Enter some appropriate input in to the web application and submit the request.
The first stage in the testing process is to submit a benign string to each entry point and to identify every location in the response where the string is reflected.
Choose an arbitrary string that does not appear anywhere within the application and that only contains alphabetic characters and therefore is unlikely to be affected by any XSS-specific filters.
The request will be captured by Burp. You can view the HTTP request in the Proxy "Intercept" tab.
You can also locate the relevant request in various Burp tabs without having to use the intercept function, e.g. requests are logged and detailed in the "HTTP history" tab within the "Proxy" tab.
Right click anywhere on the request to bring up the context menu.
Click "Send to Repeater"
Go to the "Repeater" tab.
Here we can input various XSS payloads in to the input field of a web application.
We can test various inputs by editing the "Value" of the appropriate parameter in the "Raw" or "Params" tabs.
Submit this string as every parameter to every page, targeting only one parameter at a time.
Review the HTML source to identify the location(s) where your unique string is being reflected.
If the string appears more than once, each occurrence needs to be treated as a separate potential vulnerability and investigated individually.
Determine, from the location within the HTML of the user-controllable string, how you need to modify it to cause execution of arbitrary JavaScript.
The process of crafting an XSS exploit is often one of trial and error. One must consider how to introduce JavaScript without causing an error and work around any defensive filters.
Test your exploit by submitting it to the application. If your crafted string is returned unmodified, the application is vulnerable.
In this example, we can open up a <script> tag to introduce our JavaScript.
Double-check that your syntax is correct by using a proof-of-concept script to display an alert dialog.
Confirm that this appears in your browser when the response is rendered.
Note: In any cases where XSS was found in a POST request, you can use the "change request method" option in Burp to determine whether the same attack could be performed as a GET request.
Related articles: