A penetration tester or information security researcher not finding a vulnerability in a website would be far more...
surprising nowadays than someone finding a vulnerability. This is simply the current state of information security; dedicated hackers will do whatever they can to find flaws in any website component to infiltrate and attack their victims.
Hypertext Preprocessor, or PHP, has a long history of security vulnerabilities -- as does Apache, Microsoft, Oracle and just about everyone else. However, PHP in particular has been criticized for security vulnerabilities dating back to the early 2000s, as well as allowing inexperienced programmers to develop insecure Web applications. Some of the vulnerabilities that have been discovered were in the programming language and in the PHP engine.
Recent research found that an alarming majority of PHP installations were insecure. In this tip, I will discuss the research and explain what an enterprise can do to stay secure.
Research on insecure PHP installations
In his blog post, Ferrara wrote detailed analysis of the data on PHP installs, versions and version security. If the PHP version identified on a remote system was a secure version, Ferrara counted it as secure. Ferrara also counted any PHP version as secure that didn't have a security vulnerability reported for it, but he did not use CVSS or any other vulnerability rating to further break this down. While he did identify that this might over-identify secure versions, even still, the end results are concerning: Ferrara concluded that "21.71% is an upper bound on the number of secure installs." In other words, 78% of installs were insecure.
At this point, it's time to investigate why PHP has so many security issues.
First of all, PHP has many powerful features and frameworks. It is also relatively easy for a new programmer to develop Web applications using it. These two facts create a murky picture for significant security issues for enterprises and end users. It would be impossible for the average user to tell if the website and PHP install were run by a professional staff with dedicated security resources or by a novice in his or her basement. While breaking this data down based on popularity of the website could provide additional nuances, there would still be a significant number of insecure PHP installs which, as Ferrara said in his blog, is "absolutely and unequivocally pathetic."
What enterprises can do about insecure PHP installations
There are many well-understood steps enterprises can take to secure PHP installations. The PHP Manual has an extensive security section, and there is the OWASP PHP Security Cheat Sheet, which provides basic PHP security tips for developers and admins. Following this security guidance is the first, but not the only, step for securing insecure PHP installs. The documents cover secure PHP configurations and mention secure OS and Web server configurations as well.
In addition, an enterprise should ensure PHP is checked by its vulnerability scanner and should confirm that only secure systems are exposed to the Internet. This means more than just making sure patches are installed; a current version of PHP must be installed and used. If an insecure version is identified, the enterprise owner(s) of the system should be notified and requested to update to a secure version. The owner would then need to check compatibility of the PHP code, application and any dependencies used prior to updating.
Enterprises should also ensure secure PHP programming practices are part of their software development lifecycle to prevent insecure PHP applications. Source code analysis could also be used to allow developers to fix vulnerabilities in the app prior to it going to production.
While the PHP project and ecosystem can continue to devote resources to producing secure software and configurations, increasing the priority of security over functionality to developers using and running PHP will help greatly prevent future attacks. The PHP ecosystem as a whole -- including novice developers and distributions that ship less secure configurations of PHP -- must increase the priority of security to prevent future vulnerabilities.
While the percentage of systems not keeping up with the most basic security hygiene of patching in a reasonable timeframe and using a secure configuration is quite alarming, it shouldn't be a surprise to anyone. How bad the state of security is, however, should be alarming enough to motivate more enterprises to critically analyze their information security programs and perform the difficult tasks of basic security hygiene across their networks and systems.
About the author:
Nick Lewis, CISSP, is a program manager for the Trust and Identity in Education and Research initiative at Internet2, and previously was an information security officer at Saint Louis University. Nick received Master of Science degrees in information assurance from Norwich University in 2005 and in telecommunications from Michigan State University in 2002.
Tune into this video to overcome your enterprise's patch management issues
Learn the positive effects of secure application development