The newest version of IronWASP (v0.9.6.0) comes with many improvements and features like the support for CLI based modules and the Module Creation Assistant. There is a new module included with this version, OWASP Skanda - SSRF Exploitation Framework.
They are:
* Please note that in the current version these features don't apply to Cross-site Scripting vulnerabilities.
The False Positive Detection Support is provided by the scanner giving precise and detailed information on how a vulnerability was detected and why it was reported along with instructions on how to test if it is a False Positive.
False Positive:
False Negative:
False Negatives occur when a scanner fails to detect an actual vulnerability present in an application.
To understand why that is the case we must first look at how web security scanners work. Scanners have a store of vulnerability signatures inside them. They send some payloads to the application, observe the responses that come back and check if the way the application behaved, matched any of the signatures stored inside them. When you dig beneath all the buzzwords, jargons and marketing hype, this is what you would find at the core of any open source or commercial scanner.
Signatures could be in orders of magnitude more complicated than the example cited above but all of them are ultimately very similar in principle. A signature, no matter how complex is a predetermined template defining how an application with a particular vulnerability would behave.
Notice the emphasis on the word predetermined, that is where the trouble begins. Web applications are not made from a static mould. Each application is designed differently and behaves differently. Everything from the content, the way it is laid out, the logical flow, to the way errors are handled is different in each application. Given this factor, it is not possible to come up with a template that could accurately apply to all web applications.
I have explained this in two separate posts:
But what makes this version very special is that it comes with two exclusive features that set it apart from all other web security scanners available today.
They are:
- False Positive Detection Support
- False Negative Detection Support
* Please note that in the current version these features don't apply to Cross-site Scripting vulnerabilities.
The False Positive Detection Support is provided by the scanner giving precise and detailed information on how a vulnerability was detected and why it was reported along with instructions on how to test if it is a False Positive.
The False Negative Detection Support is made possible through Anomaly detection. This is most likely the first time that Anomaly detection technique is used in the context of web security scanning.
Details on how these systems function and achieve their claimed goals is available below. But before that, if you are not very familiar with how web security scanners work and why False Positives and False Negatives occur, then the next section will bring you up to speed.
The Basics:
False Positives and False Negatives are an unfortunate reality with web vulnerability scanners. Before we delve into the details let's clarify the terminology first.
False Positive:
When a scanner reports that a particular vulnerability is present on the scanned application but in reality this vulnerability does not exist in the application, it is called a False Positive.
False Positives occur when a scanner incorrectly determines that a vulnerability is present in an application.
When a vulnerability is actually present in an application but a scanner fails to detect its presence, it is called a False Negative.
All automated web security scanners available right now produce false positives and false negatives. As a matter of fact, if Einstein, Tesla and Hawking sat down together and wrote a scanner, even that would have false positives and false negatives.
A simple signature could be that if the application returned the string 'Incorrect syntax near' when the ' (single quote) character was sent as payload to the application then it indicates the presence of Error-based SQL Injection.
Notice the emphasis on the word predetermined, that is where the trouble begins. Web applications are not made from a static mould. Each application is designed differently and behaves differently. Everything from the content, the way it is laid out, the logical flow, to the way errors are handled is different in each application. Given this factor, it is not possible to come up with a template that could accurately apply to all web applications.
Making the template very strict and specific could reduce the number of False Positives reported by the scanner but doing that would result in a lot of False Negatives. Making the template relaxed might reduce the possibilities for False Negatives but would greatly increase the False Positive count. So in general, when creating the signatures, the scanner developers settle on an optimal point between the two extremes explained above.
Now that we have dabbled a bit in the basics of web security scanner working, we can look at how the newest version of IronWASP helps the users in dealing with the inevitable problems of False Positives and False Negatives.
I have explained this in two separate posts:
Brilliant work dude, thanks so much! It would be interesting to add a function to only scan certain parts from a website. ^_^ Keep it up! (y)
ReplyDeleteThanks man! IronWASP already has ability to scan specific sections of a site. Please refer to this article to learn how - http://www.chmag.in/article/mar2013/ironwasp-series-part-%E2%80%93-1
ReplyDelete