I have been collecting statistics from my computer security research for the last few years. I decided to share them a bit. Here you can find a sample penetration test report – report. In a large number of interviews with penetration testers, I hear the question – "Has the security of web applications improved over the years?" In my opinion – yes, but only where it is somewhat forced by bottom-up regulation. Do penetration tests help improve safety? – definitely yes!
What data are we talking about?
Over the past 2 years, I have managed to perform over 100 penetration tests, security audits, analyses and retests. These were different applications for different clients. The vast majority were web applications. When an application was tested for the first time, it almost always found an error that classified the threat as critical or high. For the uninitiated, the use of this type of vulnerability leads to full control of the application (often also the server) or allows access to sensitive data.
Statistics by susceptibility classification look like this:
The detection of so many security errors in applications that has been going on for years, in my opinion, indicates that too little security time has been spent in the early stages of software development. I am thinking of educating programmers, looking at security in the very construction of software architectures and risk modelling. Without this, the vulnerabilities will still be caught at the final stage of software development (thus the cost of repair is large) or worse, only on production environments by these less ethical hackers ;).
The most commonly found vulnerabilities due to the type of
Let's look at more statistics. This time, the most commonly found types of vulnerability.
With different colors, I tried to mark the typical risk classification of a given vulnerability (of course, to put it simply, in practice it depends on many factors). In turn, it looks like this: burgundy – critical, red – high, orange – medium, green- low.
First of all, it can be seen here that XSSy are the most commonly found type of vulnerability of the most criticized ones. It is surprising to me that it has been known for about 30 years. In addition, it is perhaps the most recognizable class of security errors. Thus, its occurrence should already be rare.
In turn, there are vulnerabilities associated with authorization, which is a valid process for verifying that the user has the right to perform a particular operation. The problem is especially noticeable in applications with rich APIs.
If you look at the statistics for the most common errors – the first place is to disclose information that should not be made public. Please note that the first phase of application hacking is reconnaissance. Any redundant information that appears to be trivial may ultimately prove crucial to an effective attack.
Then, nongeneral error messages are listed. As before, they often reveal too much sensitive data, e.g. about the technologies used.
In third place is the problem, which I think will advance in the coming years in the statistics to the first position. This is a technological debt and the associated use of components with known vulnerabilities. From my point of view, today's applications are sort of composed of many small blocks and dependency chains. This causes it to turn out almost every day that a small component is already out of date. Conquering its version often involves rebuilding part of the application (at least i get such information from developers ;)), and this process unfortunately consumes a lot of resources.
OWASP Top 10 vs TOP 12 Pentester
The list of the most frequently detected vulnerabilities with the OWASP Top 10 list is as follows:
It's hard to map my "finds" 1 to 1 on the list of OWASPa. We will not find a reflection here for "Broken Authentication". This is simply because account brutforssing is mostly outside my testing range (and other errors within this point are not in my top list). In vain also look for a link to XXE. From my observations, errors of this class happen less and less often. I think this is related to the fact that the frameworks responsible for processing XMLy by default no longer allow the use of external entities. Nevertheless, the above summary shows that as much as possible the OWASP TOP 10 list is not just a dry theory and is reflected in practice. Thus, it is worth using it, as well as all the knowledge provided by the Open Web Application Security Project.
