Web vulnerabilities. Incredible - obvious
During penetration testing, security audits and other work performed by Positive Technologies experts in 2010 and 2011, statistics on the protection of more than a hundred corporate web applications were collected. It is applications, not business cards. E-government sites, Internet banking systems, mobile operators self-service portals - this is not a complete list of the objects of study.
Analysis of the results helped us to find answers to the eternal IS questions:
The answers to some of these questions, we must confess, surprised. Details - under the cut.
Yes! We found vulnerabilities in all web applications we tested, and two thirds of the resources contained critical vulnerabilities. On the chart - the top 10 vulnerabilities, indicating the proportion of vulnerable sites.
')
10% of the sites were infected with “malware”. What vulnerabilities contributed to this? Suspicion falls primarily on the execution of OS commands, as well as on the introduction of SQL code and incorrect file system permissions. Infected sites are much more likely to contain these vulnerabilities. For the OS command execution vulnerability, the difference is quite noticeable: almost all infected sites (92%) were vulnerable - unlike sites without malicious code (21%). As a result, every third site with this vulnerability was infected with malicious code.
Everyone has long wanted to know whether it is possible to use an open source CMS and is it not worth to fork out for a commercial one? or even develop your own? Our research has shown that sites built on proprietary systems contain more critical and other common vulnerabilities than sites on commercial and free systems. Plus they turned out to be, oddly enough, protection from Malvari: despite the many vulnerabilities, they are less susceptible to “accidental” hacking as part of a mass attack using automated tools, since no one will undertake to write an exploit in the hope of “stumble” on your CMS. For open systems, this was a big problem: almost a quarter were infected.
So, self-developed CMS resembles an old sieve and weave in the tail. And what about commercial and open-source? Considering the most common and most dangerous vulnerabilities, we conclude that the differences are not that great. Each group leads in its own set of vulnerabilities. For example, commercial CMSs are more likely to be vulnerable to SQL injection. But if you are sure that you are not afraid of introducing SQL-code, choose commercial CMS (they have the first place in terms of security in the overall standings). Executing OS commands, cross-site scripting (XSS), and implementing zero byte is a matter of free systems. And in terms of resistance to directory traversal and cross-site request substitution (CSRF), this is a combat draw. The critical remote file inclusion vulnerability was revealed solely on resources developed from a CMS of our own design. Below is a graph of the distribution of vulnerabilities by risk levels on sites with different types of CMS.
It is known that the "leakiness" of the site is determined at the time of language selection. The differences in this sense are stunning: systems in PHP contain critical vulnerabilities in 81% of cases, in Java - in 59% of cases, and in ASP.NET - only in 26%.
Who is afraid of what? There were no resources on ASP.NET that were vulnerable to bypassing the directory at all! Only 4% were vulnerable to the execution of OS commands. But the cross-site scripting is almost twice as rare as other sites on Java. With a small margin, Java wins from ASP.NET and in the championship on protection from the introduction of SQL-code, and PHP sadly waves it with a pen (61% of vulnerable sites - the share is almost three times higher than that of competitors). The same story with CSRF: PHP sites are twice as vulnerable. Well, only PHP sites were exposed to the introduction of the zero byte.
Having examined the web resources of the financial sector, we concluded that the situation is very depressing. Only in 10% of cases, the owners were able to fulfill the PCI DSS requirements for the protection of web applications. Well at least that no one overflowed the buffer. But incorrect error handling is typical for 76% (!) Of applications.
At the same time, the analysis of the remote banking service systems showed that they almost eliminated all critical vulnerabilities. Only 1% of RBS vulnerabilities are associated with a high level of risk.
PS The data is collected in the course of work on the analysis of the security of web applications, conducted by Positive Technologies in 2010-2011. The security assessment was carried out manually using black and white box methods using automated auxiliary means. The Web Application Security Consortium Threat Classification system (WASC TC v. 2) was used to classify vulnerabilities, with the exception of input and return data handling errors and denial of service. The severity of vulnerability was assessed according to the Common Vulnerability Scoring System (CVSS v. 2), then the high, medium and low risk levels were distinguished.
PPS The most inquisitive readers have the opportunity to get acquainted with the full version of the report .
Analysis of the results helped us to find answers to the eternal IS questions:
- how many sites are infected with malware?
- Which CMS is Safer - Commercial, OpenSource, or Is It Easier to Develop Yourself?
- Which is safer - Java, PHP or ASP.NET?
- to comply with the requirements of the standard PCI DSS– myth or reality?
The answers to some of these questions, we must confess, surprised. Details - under the cut.
Potentially dangerous?
Yes! We found vulnerabilities in all web applications we tested, and two thirds of the resources contained critical vulnerabilities. On the chart - the top 10 vulnerabilities, indicating the proportion of vulnerable sites.
')
Who pests devoured
10% of the sites were infected with “malware”. What vulnerabilities contributed to this? Suspicion falls primarily on the execution of OS commands, as well as on the introduction of SQL code and incorrect file system permissions. Infected sites are much more likely to contain these vulnerabilities. For the OS command execution vulnerability, the difference is quite noticeable: almost all infected sites (92%) were vulnerable - unlike sites without malicious code (21%). As a result, every third site with this vulnerability was infected with malicious code.
CMS: Is it worth paying for security?
Everyone has long wanted to know whether it is possible to use an open source CMS and is it not worth to fork out for a commercial one? or even develop your own? Our research has shown that sites built on proprietary systems contain more critical and other common vulnerabilities than sites on commercial and free systems. Plus they turned out to be, oddly enough, protection from Malvari: despite the many vulnerabilities, they are less susceptible to “accidental” hacking as part of a mass attack using automated tools, since no one will undertake to write an exploit in the hope of “stumble” on your CMS. For open systems, this was a big problem: almost a quarter were infected.
So, self-developed CMS resembles an old sieve and weave in the tail. And what about commercial and open-source? Considering the most common and most dangerous vulnerabilities, we conclude that the differences are not that great. Each group leads in its own set of vulnerabilities. For example, commercial CMSs are more likely to be vulnerable to SQL injection. But if you are sure that you are not afraid of introducing SQL-code, choose commercial CMS (they have the first place in terms of security in the overall standings). Executing OS commands, cross-site scripting (XSS), and implementing zero byte is a matter of free systems. And in terms of resistance to directory traversal and cross-site request substitution (CSRF), this is a combat draw. The critical remote file inclusion vulnerability was revealed solely on resources developed from a CMS of our own design. Below is a graph of the distribution of vulnerabilities by risk levels on sites with different types of CMS.
Visible to the root
It is known that the "leakiness" of the site is determined at the time of language selection. The differences in this sense are stunning: systems in PHP contain critical vulnerabilities in 81% of cases, in Java - in 59% of cases, and in ASP.NET - only in 26%.
Who is afraid of what? There were no resources on ASP.NET that were vulnerable to bypassing the directory at all! Only 4% were vulnerable to the execution of OS commands. But the cross-site scripting is almost twice as rare as other sites on Java. With a small margin, Java wins from ASP.NET and in the championship on protection from the introduction of SQL-code, and PHP sadly waves it with a pen (61% of vulnerable sites - the share is almost three times higher than that of competitors). The same story with CSRF: PHP sites are twice as vulnerable. Well, only PHP sites were exposed to the introduction of the zero byte.
Where money flows by wire
Having examined the web resources of the financial sector, we concluded that the situation is very depressing. Only in 10% of cases, the owners were able to fulfill the PCI DSS requirements for the protection of web applications. Well at least that no one overflowed the buffer. But incorrect error handling is typical for 76% (!) Of applications.
At the same time, the analysis of the remote banking service systems showed that they almost eliminated all critical vulnerabilities. Only 1% of RBS vulnerabilities are associated with a high level of risk.
PS The data is collected in the course of work on the analysis of the security of web applications, conducted by Positive Technologies in 2010-2011. The security assessment was carried out manually using black and white box methods using automated auxiliary means. The Web Application Security Consortium Threat Classification system (WASC TC v. 2) was used to classify vulnerabilities, with the exception of input and return data handling errors and denial of service. The severity of vulnerability was assessed according to the Common Vulnerability Scoring System (CVSS v. 2), then the high, medium and low risk levels were distinguished.
PPS The most inquisitive readers have the opportunity to get acquainted with the full version of the report .
Source: https://habr.com/ru/post/145329/
All Articles