[Owasp-leaders] Ruling out false positives from vulnerability scans

Rogan Dawes rogan at dawes.za.net
Mon Nov 9 03:40:44 UTC 2015


Random thought, in case any vendors are listening:

After the test run is complete, and there is no longer any excessive load
on the target, repeat any time-based tests that resulted in a finding,
perhaps with a really large expected delay, like 30-60 seconds, to validate
and eliminate false positives.

Rogan

On Mon, 9 Nov 2015 03:25 Michael Born <michael.born at owasp.org> wrote:

> Laura,
>
> I echo Brad's response with one addition. False positive analysis and
> manual testing should be a part of any service providing vulnerability
> assessments. If you are just paying for a scan and dump from a service
> provider or if internal teams are ONLY scanning and then dumping the report
> into other teams' laps, that's a problem. The Security team or the service
> provider should work with you to thoroughly go through the scan results and
> report to eliminate false positives.
>
> I find that if folks just took the time to run a sqlmap follow up scan
> configured appropriately for the environment to validate all SQL injection
> results from a vulnerability scan, it would make this process a lot
> smoother for this particular kind of vulnerability. With that said though,
> I know from experience that environments can't always handle an attack tool
> like sqlmap as a way to validate SQL Injection.
>
> Like Brad indicated, Blind SQL injection vulnerabilities have a horrible
> track record with Vulnerability scanners. Log correlation with database and
> application logs are a good way to validate SQL Injection although this can
> be pretty time consuming.
>
> Michael Born
> OSCP, CISSP, C|EH
> Omaha OWASP Chapter Co-Leader
>
> Sent from my autocorrect defunct smartphone.
>
> On Nov 8, 2015, at 17:42, Brad Causey <bradcausey at gmail.com> wrote:
>
> We use a combination of manual testing and developer/DBA reviews.
>
> Of course this is dependent on your relationship with the application
> developers.
>
> Things like Blind SQLi are especially bad about being false positives
> because most scanners use delay injection to determine vulnerability state.
> This isn't a great method because you also just happen to be hammering the
> site at the same with other requests that will impact it's performance.
>
> In this anecdotal case, it's easy to determine if the injection made it
> into the database because we can request database logs or ask the DBA to
> check it out. Of course, we are again assuming they are trustworthy and
> reliable.
>
> Barring those options, we'll manually reproduce the test using a proxy
> tool to see if we can replicate the issue.
>
> All of this can be rather tedious, so we only do it for higher risk
> issues.
>
> I hope this helps!
>
> -Brad Causey
> CISSP, MCSE, C|EH, CIFI, CGSP
>
> --
> "Si vis pacem, para bellum"
> --
>
> On Sun, Nov 8, 2015 at 5:37 PM, Laura Guazzelli <laura.guazzelli at owasp.org
> > wrote:
>
>> Hello,
>> I am very curious about either the methodology and/or recommendations
>> from leaders on how to separate false positives from real positives from
>> vulnerability scans.
>> Thanks,
>> Laura Guazzelli
>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>
>>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20151109/927c3a2c/attachment-0001.html>


More information about the OWASP-Leaders mailing list