When I tell someone that Netsparker is “False Positive Free”, they’ll stare at me and think “Well, yet another lunatic!” They never actually said that but I can read it from their faces. They won’t say much assuming I’m a mad person who claims a scanner can avoid false positives and since I’m a mad person, I can be dangerous. I assume that’s why they generally choose to be silent after that claim!
Then I ask them a simple question:
“If you can exploit a vulnerability, can that be a false positive?”
Instantly they say “No”, then another 15 seconds of silence before they realise Netsparker actually exploits the identified vulnerabilities to ensure that the vulnerability is not a false positive.
“If you can exploit, it can’t be false positive”. End of discussion.
Obviously you can’t exploit everything. You can’t exploit and confirm an “internal path leakage” vulnerability without actually compromising the system via another issue. You can’t be sure if the exposed error message is actually something dangerous or just a static text.[i]
So there you go, you can confirm almost all important issues, because all important issues have a clear impact via exploitation. It’s a huge challenge to do this automatically, though. Manually a pen tester can simply figure out the structure of an SQL Injection but automatically it takes some good engine to figure that out. I’m happy to say that with Netsparker we managed to do this quite successfully.
Netsparker made false positive free reporting a reality rather than an urban legend. I’m sure other scanners will follow us. We are happy to change the world of automated application security scanning by introducing the first “False Positive Free Web Application Security Scanner”. Also another first is “Integrated Exploitation Engine”. So you get the whole package, crawl, detect, confirm and exploit.
We don’t claim every single issue we report is false positive free. What we claim is if Netsparker confirms an issue then it’s not a false positive and we’ll easily confirm %80 or more of the identified issues. If we can’t exploit it, it’ll still be reported as [High] or [Low] possibility depending on the other factors.
If it was a real vulnerability and Netsparker couldn’t confirm it, all you need to this contact us and we’ll fix it.
There are many issues where it’s not possible to confirm the identified issue hence we do report them as “[Possible]” so the user knows if the vulnerability has been confirmed or not. The beauty of this is that if the report says “Confirmed”, you know you can trust it. Don’t believe it? Use the integrated exploitation panels to exploit the vulnerability yourself. Generally it only takes two clicks.
[i] Although you can guess based on some indicators such as if the HTTP status is 500 and then there is higher possibility that it’s not a false-positive. Hence Netsparker will report issues as [High Possibility] or [Low Possibility] based on similar indicators.