On Thu, Oct 16, 2008 at 11:43:09PM +0200, Shachar Shemesh wrote: > > 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.
Hi Shacher, Interesting, I was at a technical sales pitch for one of beyond's automated scanners about three years ago. The salesman repeated the claim that their scanner can locate 99 percent of "zero day" vulnerabilities in a web application at least three times during that presentation. I did not think that any automated scanner could properly test for all of the WASC vuln classes back then, and although the scanning technology has somewhat improved, it can not properly test for all WASC vuln classes now. > > 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. Fuzzing parameters is something scanners should do well in theory and can do well under certain predictable situations. You need to differentiate between generic plugins in scanners like Nessus, OpenVAS or even dedicated web app scanners like w3af and a custom plugin / script that was written specifically for a certain app, that understands what each parameter in a request actually does and understands whether the response received is indicative of an vulnerability or not. This is usually easy for XSS plugins, but much more difficult (if not impossible) when writing a generic plugin for other flaws such as insufficient access controls, for example. This is just one of the areas where running an automated scanner against a web app fails. Having said that, I do like web application scanners and use them often, just that they are no replacement for manual testing. Receiving a clean report from an automated scanner often gives clients a false sense of security. Its important that they understand the limitations involved in both manual and automated testing. > 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". > > Conclusion: Automatic, and semi automatic tools, can be a great help. It sounds like you agree with my original statement that if the web app is high risk, then manual testing should be used in conjunction with automated testing. -- - Josh ================================================================= 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]
