Re: Of the three expensive vulnerability scanners

[Tom Stracener <strace () gmail com>]

In-Reply-To: <003801c4c9c6$e5f39530$8d8606d1@rockstar>

Jim,

The problems you've mentioned with regard to the Cross Site Scripting tests point to a functionality area where the 
major players in the App security market need major improvement. As Jeremiah pointed out, the problem is broader than 
XSS policies alone, but it certainly affects them. 

One reason the XSS policies yield diminishing returns and are poorly organized in reports is due in part I believe to a 
lack of proper detection mechanisms. Both products use a plethora of fault injection techniques, yet neither seems 
sensitive to whether or not the injected script is returned within the context of the app's response in a form that is 
executable by a browser. As a result, when one form field is vulnerable to XSS, you can get into situations where 
virtually every XSS test returns with a positive detection.

As you've no doubt noticed, each product checks for various kinds of XSS, some of these kinds are distinguished on the 
basis of the delimiter that is used. Despite the technical differences, each delimiter type has a sophisticated name 
(i.e Double Quote Single Quote Bracket kung fu, etc.)

">&lt;script ....
'>&lt;script ....
">">&lt;script ...
<--&lt;script ...
<textarea>&lt;script ...
etc.

While the main vulnerability condition is whether or not an application will "echo back" the script sequences, real 
problem is that the different delimiters are important because some will execute when returned by the application, and 
others will not, depending upon the HTML/Script code of the application. This is why it is important to audit the 
application's logic, but there really is no reason to test for 12 different types of cross site scripting scenarios 
using different delimiters and script types if the detection mechanism can't account for which sequences actually yield 
results that are executable. 

The optimal solution in my opinion would be to emulate a browser and trap for alerts (or other events) and then to 
organize the report data based on which delimiters successfully generated the desired pop-ups (or whatever event is 
trapped for). The rest could be classified as warnings. This would help to minimize the multiple alerting problems that 
plague the XSS tests and produce frequently confusing results. While this wouldn't fix the reporting problems, it would 
help to attenuate the signal.

-tom