Re: Of the three expensive vulnerability scanners

[<ban.marketing.bs () hushmail com>]

OK what am I missing here? Why use a fundamentlaly floored 
technique for finding the issue? Why not look at the source? Its 
pretty damn obvious where you are reading or writing unvalidated 
data....please please no "source is not always available" 
junk.....this is the web and 99% your looking at bespoke apps. You 
have to ask or educate the client at worse. 

Its about time the industry started taking software security 
seriously and continuing down this futile route of refining pen 
testing techniques to make up for the obvious limitations of this 
technique is not it IMHO.

Newsflash - Most serious XSS issues in the real world are stored 
not refelcted and unless you can trace data to the reflection point 
this technique will NEVER find them ! 



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





Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427