Slashdot Mirror

← Back to Stories (view on slashdot.org)

Over 78% of All PHP Installs Are Insecure

Posted by Soulskill on from the 2015-will-be-the-year-of-distrust-on-the-internet dept.

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.

4 of 112 comments (clear)

  1. Re:ircmaxell by ircmaxell · · Score: 5, Interesting

    Thank you for the kind words :-)

    --
    If a man isn't willing to take some risk for his opinions, either his opinions are no good or he's no good
  2. Re: PHP by Anonymous Coward · · Score: 2, Interesting

    I've programmed heavily in both PHP and .NET and I can say the PHP upgrades are not the cause of security issues. PHP's weakness is a combination of being interpreted at runtime and not enough access to the kernel. Things break heavily between .NET versions yet those developers do not jump ship over it. As PHP moved towards being more object oriented the implementation of it changed. Code which ran in a safe manner previously all of a sudden is a security problem. In .NET things are structured so that in the same scenario the older code would just fail completely. Neither languages are perfect at security but in the case of PHP it comes down to how you use it. For instance C is very *unsafe compared to the structure of C++ depending on how it is used.

  3. Re:Bogosity by ircmaxell · · Score: 3, Interesting
    There's a difference between a vulnerability and an attack vector. Even if it's not exploitable, the vulnerability still exists.

    However, I would like to make a point. How many of these installs made a conscious decision by investigating the security fixes and balancing that against their codebase to see if it's exploitable or not? I'd wager that the number is so small as to not even register.

    Besides, I think a variant of Schneier's law applies:

    "any person can invent a security system so clever that she or he can't think of how to break it."

    The same thing applies to vulnerabilities: If you can't think of a way to exploit it, that doesn't mean it isn't exploitable.

    So yes, it is an over-statement. But it's also showing quite clearly how updates are being dealt with. And that was the precise point of the original post. If it gets people to think about upgrading more, then awesome. If not, nothing lost.

    --
    If a man isn't willing to take some risk for his opinions, either his opinions are no good or he's no good
  4. Re: PHP by Anonymous Coward · · Score: 2, Interesting

    This.

    Old php3 / php4 dev here. Moved to python when got the chance.

    I think that one of the main reasons for not updating PHP on production arises from its interpreted nature, and some other come from the language itself. First, there is no mechanism to know if an application will work with a new version of the interpreter before running into production. You may say your test coverage is nearly complete, but: a) that leaves some code untested, and b) most of the php apps I've found have zero tests. Then, you just update php in your servers and wait 'til the users report all the bugs found along the way. There's lint, but mostly at the syntax level, and that won't find things like deprecated functions or changes in return values/arguments between versions. And finally, there's the php non-standard-way of error handling: nothing beats a 500 error or a blank page straight to the user.

    If there were a way of checking the compatibility of a full source tree against a particular php version, be it by statical or dynamic analysis but verifying all the code paths, something like:

    $ ./oh_please_tell_me_this_source_works_with_5.4.23 ./trunk
    Yes. ... the number of updated platforms would be different.

    Note that python (and most of the interpreted languages) share this problem, but the strong typing and exception handling make it less problematic.