Over 78% of All PHP Installs Are Insecure

An anonymous reader writes: Anthony Ferrara, a developer advocate at Google, has published a blog post with some statistics showing the sorry state of affairs for website security involving PHP. After defining a list of secure and supported versions of PHP, he used data from W3Techs to find a rough comparison between the number of secure installs and the number of insecure or outdated installs. After doing some analysis, Ferrara sets the upper bound on secure installs at 21.71%. He adds, "These numbers are optimistic. That's because we're counting all version numbers that are maintained by a distribution as secure, even though not all installs of that version number are going to be from a distribution. Just because 5.3.3 is maintained by CentOS and Debian doesn't mean that every install of 5.3.3 is maintained. There will be a small percentage of installs that are from-source. Therefore, the real 'secure' number is going to be less than quoted." Ferrara was inspired to dig into the real world stats after another recent discussion of responsible developer practices.

Comments

ircmaxell

[TheNinjaroach]

I would have never recognized him by the name Anthony Ferrara, but ircmaxell immediately rings a bell for me. That dude is smart, kind and helpful in situations on IRC where most people aren't. He took a lot of time helping me get a patch or two submitted and accepted into PHP, in spite of my rudimentary git submissions.

If you're reading this ircmaxell, thanks for the help. The PHP Project is better for it.

PHP

[ledow]

And why?

Because upgrading PHP breaks shit. It's the old story of backwards compatibility versus security and, inevitably, when you've commissioned a website in a language that you can't program in yourself, you will choose backwards compatibility every time.

Most people do not host their own web services. As such they are at the mercy of their host and what their host needs to run for everyone to be happy.

Every web host I've ever used, personally or professionally, will give you a version of PHP and rarely update it. When they do, they will invariably warn you that your scripts (i.e. website) are probably about to break. Most people in that position do not have the skills and knowledge (or even the tools or hosting capability!) to log in and fix the problem. So it's "we're going to break your website... you have to pay money to fix it".

Hence, there is a pushback every time they do it, and that makes them even more reluctant to suggest to their users that they need to do it again next month.

This is partly a user problem, yes, but it's mainly in the court of the PHP developers. Why does going from PHP 5.3 to 5.5 break SO MUCH without reason? Almost every bulletin board, forum, image gallery or what-have-you you find that runs PHP tells you version it will work on, and has had to issue at least one update that fixes shit that breaks on the newer versions of PHP.

I'm not sure there's another language out there that's quite so undefined and variable when it comes to how things should work and what could change/break in new versions.

Sure, I get that we have to keep everything up-to-date when we're running net-facing servers, but the problems of PHP compatibility and that most web-hosts are scared to upgrade has caused more problems than those old scripts still running. For the most part, they are even worked around so they are still compatible with old PHP's rather than, as should happen, upping the minimum required PHP version and making people get secure throughout.

I think we can safely lay the majority of this problem on the removal of register_globals (something that should never have existed in the first place), magic quotes and safe mode. The last two of which were touted as the lazy-man's security functions so you didn't have to worry about all the fine detail. The rest of the changes in those versions are pretty minor and to-be-expected of a new version of software.

If PHP hadn't done a "PHP isn't safe", "Here, use this hodgepodge of half-assed security feature", "Shit, they're more dangerous than what we were avoiding, remove them!", then maybe they wouldn't be in this mess.

Re:PHP

[Trane Francks]

There is a lot of angst here, but the reality is that putting a CMS online is not the end of the task, it's the beginning. If you want to have a public-facing web site, that means keeping it up to date so that providers have no qualms about upgrading. In many cases, the issue isn't the client, per se, but the requirements of the client site that slow down upgrading. As an example, Zend still hasn't managed to add PHP 5.5 support to their Guard product, so anybody who has clients using Zend in their sites will be stuck on 5.4.x till, well, whenever Zend gets a move on.

In any case, running a provider is a matter of pushing clients to keep up with server changes in a timely yet forgiving fashion. There's no reason that upgrading from PHP 5.4.35 to 5.4.36 should break ANYthing, so there's no excuse for a provider to not keep up with patch releases. Moving from 5.4 to 5.5, for example, will introduce potential incompatibilities, so providers need to give 30-60 days advanced notice to ensure client sites can be checked and upgraded as required. As long as plugins and CMS releases have been updated as they come along, the reality is that most upgrades are pretty painless. It's the big-jump scenario, 5.2-5.5 kind of upgrade that will be a nightmare. Those should never happen.

A good provider will retain legacy servers for those who still toddle along with FrontPage extensions and the like, but only till such time as the base services, e.g., Apache 2.2.x and PHP 5.4.x reach end of life. At that point, a provider needs to come to the realization that putting an entire server at risk at the behest of a few clients who are slow with the updates is bad business. PHP might have its downside, but keeping in tight lockstep with upgrades keeps things (usually/hopefully/OMG-I-pray) one step ahead of the kiddies and blackhats.