August 28, 2014 at 16:03Study: PHP sites turned out to be the most vulnerable for hackers
An attack on a corporate website not only disrupts the operation of online services and undermines the reputation of owners, but often becomes the first step in breaking into the internal networks of large companies. At the same time, according to a study by Positive Technologies, the number of sites with high-risk vulnerabilities has recently increased significantly. Researchers have identified the most common vulnerabilities and evaluated how effective their detection methods are.
In total, during the security analysis tests conducted by the company in 2013, about 500 websites were studied, for 61 of them a more in-depth analysis was conducted.
A significant part of the investigated portals belonged to banks - due to the increased attacks in this area. The demand for security analysis of media sites has also increased, due to high-profile cases of hacking and the spread of misinformation. In addition, the sites of government agencies, industrial enterprises and telecommunications companies were examined.
It turned out that 62% of sites in 2013 contained high-risk vulnerabilities. This indicator is significantly higher than last year (45%). Most applications with high-risk vulnerabilities were detected on media sites (80%). As for the remote banking services sites, none of the investigated RB systems fully met the requirements of the PCI DSS security standard.
The most common vulnerabilities (percentage of sites,%)
The most common vulnerability of 2013 - cross-site scripting (Cross Site Scripting) - occurs on 78% of the sites examined. This drawback allows an attacker to influence the contents of a web page displayed in the user's browser, including for the purpose of distributing malicious code or obtaining victim credentials. For example, in the case of a vulnerable Internet banking system, an attacker can generate a link related to the real site of the bank, upon clicking on which the user will see a fake login form. The data entered by the user will be directed to the attacker server.
In second place in popularity (69%) is insufficient protection against the selection of user identifiers or passwords (Brute Force), for example, due to the absence or incorrect implementation of the CAPTCHA mechanism. The top 10 also included two high-risk vulnerabilities - Embedding SQL Statements (43%) and Embedding External XML Entities (20%).
The sites that were written in PHP turned out to be the most insecure: 76% of them contain critical vulnerabilities. Web resources in Java (70%) and ASP.NET (55%) are less vulnerable. Dangerous vulnerability “Implementation of SQL statements” is found in 62% of sites written in PHP; for other languages, this indicator is much lower.
Positive Technologies experts also conducted a comparative analysis of application testing using black, gray and white box methods. The black box method involves examining the system without receiving data about it from the owner; the gray box method involves an intruder who has some privileges in the system; and finally, the white box method means analysis using all the internal data about the system, including the source codes of the programs.
Among the web resources investigated by the methods of black and gray boxes, critical vulnerabilities were found in 60% of sites. For the white box method, this figure is higher - 75%.
The average number of vulnerabilities on one site with different testing methods taking into account the degree of risk
From the average number of vulnerabilities per system, it follows that white-box testing can detect almost 10 times more critical vulnerabilities than black-and-gray box testing. If possible, analyze the source code of web applications, the white box method is preferred. But while site owners rarely resort to it: only 13% of web resources were investigated using this method.
Read the full study on the Positive Technologies website: www.ptsecurity.ru/download/PT_Web_application_vulnerability_2014_eng.pdf
PS In continuation of the topic, on September 04, 2014 at 14:00 a webinar “Recommendations of the Central Bank on ensuring information security of automated banking systems” will be held. On it we will try to talk about why the document turned out to be so, why it does not have SSDL / SDLC explicitly, and highlight other issues that arose.
You can register here .
In total, during the security analysis tests conducted by the company in 2013, about 500 websites were studied, for 61 of them a more in-depth analysis was conducted.
A significant part of the investigated portals belonged to banks - due to the increased attacks in this area. The demand for security analysis of media sites has also increased, due to high-profile cases of hacking and the spread of misinformation. In addition, the sites of government agencies, industrial enterprises and telecommunications companies were examined.
It turned out that 62% of sites in 2013 contained high-risk vulnerabilities. This indicator is significantly higher than last year (45%). Most applications with high-risk vulnerabilities were detected on media sites (80%). As for the remote banking services sites, none of the investigated RB systems fully met the requirements of the PCI DSS security standard.
The most common vulnerabilities (percentage of sites,%)
The most common vulnerability of 2013 - cross-site scripting (Cross Site Scripting) - occurs on 78% of the sites examined. This drawback allows an attacker to influence the contents of a web page displayed in the user's browser, including for the purpose of distributing malicious code or obtaining victim credentials. For example, in the case of a vulnerable Internet banking system, an attacker can generate a link related to the real site of the bank, upon clicking on which the user will see a fake login form. The data entered by the user will be directed to the attacker server.
In second place in popularity (69%) is insufficient protection against the selection of user identifiers or passwords (Brute Force), for example, due to the absence or incorrect implementation of the CAPTCHA mechanism. The top 10 also included two high-risk vulnerabilities - Embedding SQL Statements (43%) and Embedding External XML Entities (20%).
The sites that were written in PHP turned out to be the most insecure: 76% of them contain critical vulnerabilities. Web resources in Java (70%) and ASP.NET (55%) are less vulnerable. Dangerous vulnerability “Implementation of SQL statements” is found in 62% of sites written in PHP; for other languages, this indicator is much lower.
Positive Technologies experts also conducted a comparative analysis of application testing using black, gray and white box methods. The black box method involves examining the system without receiving data about it from the owner; the gray box method involves an intruder who has some privileges in the system; and finally, the white box method means analysis using all the internal data about the system, including the source codes of the programs.
Among the web resources investigated by the methods of black and gray boxes, critical vulnerabilities were found in 60% of sites. For the white box method, this figure is higher - 75%.
The average number of vulnerabilities on one site with different testing methods taking into account the degree of risk
From the average number of vulnerabilities per system, it follows that white-box testing can detect almost 10 times more critical vulnerabilities than black-and-gray box testing. If possible, analyze the source code of web applications, the white box method is preferred. But while site owners rarely resort to it: only 13% of web resources were investigated using this method.
Read the full study on the Positive Technologies website: www.ptsecurity.ru/download/PT_Web_application_vulnerability_2014_eng.pdf
PS In continuation of the topic, on September 04, 2014 at 14:00 a webinar “Recommendations of the Central Bank on ensuring information security of automated banking systems” will be held. On it we will try to talk about why the document turned out to be so, why it does not have SSDL / SDLC explicitly, and highlight other issues that arose.
You can register here .