Blind XSS11th August 2018
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.
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 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 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
A special mention goes out to @dolyersec for pointing out the open source version of XSS Hunter to me.