Josh Amishav-Zlatin wrote:
Hey Aviram,
Aviram is cooling off. We all lose our temper every once in a while.
I'll do my best, but the text below is based on my (probably flawed)
understanding of Beyond's product.
though I have yet to see an automated scanner, including yours, that finds
all
I have not found anyone willing to attest to "all" at all, no matter the
cost and no matter the tool.
(or even most) blind SQL injection vulns.
You might be right. I am yet to find anyone even seriously looking for
them :-)
What (some of) the products by Beyond do, however, is to manually set
the path, and then automate this for other URLs/later site updates. So
it may not (I don't know) check for all blind SQL injections
automatically, but it certainly shortens the time and effort needed to
carry out those tests.
The truth is automated
scanning is good at catching the low hanging fruit. It can be a useful
tool when used in conjunction with proper manual testing.
As far as I know, that is precisely what Beyond is doing (not for $30,
though).
However, it
would be naive to believe that an application is free from high risk
vulns just because it passed some automated scan.
Well, it would be naive to think that merely because an application was
audited by four highly known pen-testers scanning each line that it is
free from high risk vulns. So, yes, obviously the second option will
provide better promises of safety, but that's just it - it is all about
trade offs. The more automated a test is, the less it is going to find,
but the less it is going to cost. I did think, upon hearing the
(technical) sales pitch that (some of) beyond's products break the line
between "high assurance" and "cheap", which means they may be cost
effective (again - sometimes, and depending on how much their cost) for
your need.
I think you know as
well as I do the limits in writing generic plugins that are successful in
identifying a specific vuln in a custom app 100 percent of the time. For
example, how many automated scanners can identify insufficient access
control vulns where by rotating a number in the request, you can
access arbitrary client information? An automated scanner has no way
of knowing the meaning of the 'clientID' parameter, or whatever
arbitrary name the developers gave it.
Actually, fuzzing parameters is something I think many automatic
scanners should do. I have to admit total rust in that area, so I cannot
tell whether they actually do, but Like Halvar Flake once said - the
best fuzzing tool he knows is called "perl".
I should point out that I once spent a week of peeking my eyes out at
the code for FW-1 version 4 (aka CheckPoint 2000), looking for format
string vulnerabilities. Come the following week, "all" that I had to do
was repeat the process with version NG of the same program. I spent a
couple of days writing a program that will do the "grep" for me,
eliminating the major class of false positives. The remaining three days
were enough to scan the (larger) mass of code for the new version.
A couple of months later, a hacker found a format string vuln in
CheckPoint 2000. When we went to fix it, I went to check whether the
same problem didn't affect NG as well. It didn't - I found it there and
fixed it. The manual scan made me miss some secondary format string
functions, which I successfully found using the help of a tool.
Conclusion: Automatic, and semi automatic tools, can be a great help.
There is no reason to knock ALL of them off, merely because they don't
reach an Utopian 100% mark that is impossible anyways.
Shachar
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
