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.)
"><script ....
'><script ....
">"><script ...
<--<script ...
<textarea><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
