On Security and PHP

      40 Comments on On Security and PHP

This is an Opinion/Editorial (a.k.a an Old Man Rant)

2: “PHP IS INSECURE!”. Yet another consultant group has decided that their traffic stats are too low so they need to “shake things up a bit”. As usual, they picked PHP as the whipping boy. No, I am not going to link to them; too many people are already doing that unironically.

The report that came out has this incredible insight.

“In particular, note that applications in truly compiled application languages like C/C++ and Objective C (iOS) have a higher OWASP pass rate than general-purpose bytecode languages like Java or .NET, while scripting languages like Classic ASP, ColdFusion and PHP have a far lower pass rate.”

(Yes, that is a direct quote)

So we have a consulting group that has discovered that compiled languages have fewer security issues than dynamic languages. In other news, water is wet. This insight isn’t a revelation to anyone who has worked with a compiled language.

Because that isn’t quite enough, they use this amazing fact to tar PHP specifically.

This is of concern given the large numbers of web applications written atop PHP-based content management systems such as WordPress and Drupal.

Ignoring for the moment any and all other dynamic languages.

Yes, PHP is used in approximately 50% of all web applications and yes, by some accounts it is installed on 80% of all Internet servers. There are however other options and many companies utilize them, in no small part because of reports like this one.

“Yes, but PHP is insecure.” I hear people saying. “I saw it on [reddit|HN|some other place haters gather to hate].” I do not argue the point that the PHP language itself does have security issues in it. The ones left though are the unknown ones. The Core does a good job of responding to attack vectors when they are reported. Solutions are found, new versions are released. That should solve the problem, right? Well actually…no.

Jack Skinner just released a great analysis of the versions of PHP that are installed in production,”PHP Version Roundup PHP Install Statistics for 2015“. In this post, he does some interesting analysis of the numbers. While it is depressing the number of servers not running at least 5.6, what is worse is that many of the servers running unsupported versions of PHP aren’t even running the secure version of their branch. There is a weak argument to be made on not updating servers to the latest version, but there is no excuse whatsoever for not making sure that the the most secure point release of the version is installed. Jack summed it up most eloquently at the end of his post when he said:

‘Patch Yo Sh*t!’

Then there is the real problem that the consultants were trying to highlight. Code written by PHP developers is perceived to be less secure than code written by Java, iOS, and .NET developers. While they do quote statistics to prove their point, they manage to leave out all details about how they gathered their statistics. Was the code they analyzed old PHP3 code? PHP4 code? Was there a predominant framework? We aren’t given that level of detail because it would allow us to possibly draw conclusions other than the ones they want us to draw.

Yes, code written in PHP has a reputation of being less secure. The PHP community works diligently with help from people like Chris Shiflett and Chris Cornutt to educate developers about best practices in security. It is difficult to attend a PHP conference these days without seeing sessions on how to write secure PHP code. Here at Zend, one of our most popular classes is “Building Security Into Your PHP Applications” in which we teach PHP developers about the OWASP Top 10 and how to write secure PHP code.

We can all agree that PHP code used to be notoriously insecure due in part to it’s low point of entry, but so was the entire Internet. As we learn, we are writing better and more secure code. Sadly reports like the one highlighted here do nothing more than perpetuate old stereotypes. The truth is that yes, PHP code has flaws, much like Python code, node.js code, and Ruby code. We’ve got fewer this year than last, and hopefully, we will have fewer next year. We are getting better. Sadly, not all applications get better at the same rate. Some people just will not bother to patch old code. That is not a language problem, that is a people problem. (It doesn’t lessen the importance of the problem, but let’s at least properly identify it)

fClose();

So yes, PHP can be insecure, it is as insecure as any other code used on the Net. Yes, there is old and insecure PHP code out there that is still in production. There is old Java code out there that is insecure and still in production. We as a community are working to clean up our little patch of the Internet. Instead of hand waving and vague warnings, it would be awesome if consultant groups like this who write bad articles as link-bait would help the community identify the problems so that we can work with the developers to correct them. But sadly, that doesn’t build traffic like a good clickbait article.

 

Photo Credit: 2: by Amy McTigue
Used under Creative Commons Attribution, No Derivatives 2.0 License