Smart DOM XSS Detection in Qualys WAS
Last updated on: December 20, 2022
Recently Qualys extended the cross-site scripting (XSS) detection capabilities of Qualys Web Application Scanning (WAS) by adding a new mechanism for detecting DOM based XSS (DOM XSS) vulnerabilities. The new mechanism works in an automated manner with no special setup or knowledge requirements, enabling security teams to greatly reduce the risk from these typically hard-to-detect vulnerabilities. Because of the technique Qualys WAS uses, it also indicates the location in your code of any XSS bugs found, which is pretty convenient for your development teams.
To understand the significance to web application security teams, let’s take a deeper look at XSS and the special case of DOM XSS.
There are three main forms of XSS vulnerabilities: reflected XSS, stored XSS and DOM XSS.
Some examples below will shed light on how this can be done.
With any XSS, the attacker can perform a number of damaging actions, such as stealing session cookies, redirecting to unwanted/malicious websites, and more. So these are vulnerabilities you want to fix.
Challenges with Automated Detection
First a few definitions will help describe how DOM XSS works and shed light on how it can be detected.
Sources and Sinks
Examples of DOM XSS sources are document.URL, cookies, referer header.
Examples of easy-to-exploit sinks are eval, document.write, setTimeout.
Examples of DOM XSS Vulnerabilities
An example of such a cookie could be:
Set-Cookie: badCookie=<script>alert(1)</script> Path=/; Domain=.foo.com
Detection via Taint Propagation (phase 1)
The greatest benefit of the DOM XSS detection method employed in Qualys WAS is that the taint propagation check is done during natural crawling and web application progression. That means there is no need to artificially simulate user interaction with the web application — the Qualys WAS crawler already does that.
Details of Possible DOM XSS Vulnerabilities via Taint Propagation:
Source: location JS call stack: function: element.innerHTML Sink: element.innerHTML
The details similar to the one above are helpful as there are few details reported, but these are then used to dig a bit deeper in the phase 2.
Detection via Exploitation (phase 2)
Details of Reported DOM XSS Vulnerabilities:
Here is an example of data that could be collected by Qualys WAS via taint propagation:
Source: cookie JS call stack: function: document.write Sink: document.write
And additional details that could be collected via exploit backtrace:
_exploit_dom_xss global code@http://Vulnerable.site/Simple-Cookie.html:1 write@[native code] call@[native code] write global code@http://Vulnerable.site/Simple-Cookie.html:9
As you can see, the exploit backtrack shows you specifically what calls are part of the exploit path, so you can rewrite them to avoid the reported vulnerability.
Fixing DOM XSS Vulnerabilities
Since Qualys WAS performs both taint propagation check and exploitation, it reports very few false positives. That’s because the exploitation check ensures that the vulnerability in question could be exploited.
Great work and excellent article, Vaagn!