Having analyzed the results, we could finally answer the perennial questions of information security:
• How many websites are infected with malware?
• Which CMS is securer: commercial, open-source or a self-developed one?
• Which is the securest among Java, PHP and ASP.NET?
• Is it a myth or reality to comply with the PCI DSS requirements?
Some of the answers to these questions surprised us, we must say. See details under the cut.
Yes! We found vulnerabilities in all tested web applications, and two thirds of the resources contained critical vulnerabilities. The diagram presents top 10 vulnerabilities with indication of the percentage of vulnerable websites.
10% of websites were infected with malware. What vulnerabilities made it possible? OS Commanding, SQL Injection and Improper Filesystem Permissions are the primary suspects. These vulnerabilities appeared on the infected websites much more often. The difference is obvious for OS Commanding: almost all infected websites (92%) were vulnerable as opposed to websites not affected by malware (21%). As a result each third website containing this vulnerability was infected with malware.
It is a common question whether it is reasonable to use an open source CMS or it's better to fork out for a commercial or even self-developed one. Our research showed that websites built on self-developed systems contain more critical and other vulnerabilities than websites based on commercial and freeware systems. Curiously enough, one of the advantages of such systems is that they are well protected against malicious software — despite multiple vulnerabilities, when a mass attack using automated tools is conducted, the risk of accidental hacking is rather low, because nobody wants to write an exploit hoping to run into your CMS. It has become a huge problem for open-source systems — almost a quarter of them were infected.
Thus, self-developed CMSs resemble an old sieve, and drag behind. And what about commercial and open-source systems? Considering the most widespread and dangerous vulnerabilities, it can be concluded that the difference is not so big. Each group is leading in its set of vulnerabilities. For example, commercial CMSs are mostly vulnerable to SQL Injection. However, if you are sure you can cope with attempts of SQL injection attacks, then choose commercial CMSs (they are the leaders in security). OS Commanding, Cross-Site Scripting (XSS), and Null Byte Injection are free systems’ lot. As to the level of resistance to Path Traversal and CSRF, they are equal. Remote File Inclusion was detected only on resources with a self-developed CMS. The following diagram shows how the vulnerabilities are allocated on websites with different CMSs according to their severity.
Getting to the root
It is well known that the number of breaches is predetermined by a chosen language. The difference is really tremendous: PHP based systems have critical vulnerabilities in 81% of cases, Java based systems — in 59% of cases, and ASP.NET based systems — only in 26%.
What are the threats? There are no resources on ASP.NET vulnerable to Path Traversal at all. Only 4% were vulnerable to OS Commanding. Java based websites are almost twice less vulnerable to XSS. Java wins by a small margin over ASP.NET in issues of protection against SQL Injection, and PHP drags far behind (61% of vulnerable websites, it is three times higher comparing to the same index of its competitors). It is the same with CSRF — PHP based websites are two times more vulnerable. As to Null Byte Injection, it is typical only of PHP websites.
Having considered financial sector web resources we arrived at the conclusion that the situation was rather depressing. Only in 10% of cases owners of web applications managed to comply with the PCI DSS web application security requirements. At least, there were no cases of Buffer Overflow. However, Incorrect Error Handling is typical of 76% (!) of applications.
At the same time remote banking system analysis showed that practically all critical vulnerabilities were fixed in them. Only 1% of vulnerabilities in the remote banking systems had high severity.
P.S. This data was collected while analyzing web application security by Positive Technologies in 2010—2011. Security was assessed manually by means of white and black box testing conducted with the help of automated tools. Web Application Security Consortium Threat Classification (WASC TC v. 2) was implemented for classification of vulnerabilities, except for input and output handling errors and Denial of Service. Vulnerability severity was assessed according to the Common Vulnerability Scoring System (CVSS v. 2), and then high, medium, and low risk levels were assigned.
P.P.S. The most curious readers have an opportunity to view the full version of the report here.