Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
PHP Programming Security The Internet

Over 78% of All PHP Installs Are Insecure 112

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.
This discussion has been archived. No new comments can be posted.

Over 78% of All PHP Installs Are Insecure

Comments Filter:
  • by Marc Nicholas ( 3924913 ) on Tuesday December 30, 2014 @09:04PM (#48700959)
    Well, some therapy should help them overcome their insecurities!
    • by RoLi ( 141856 ) on Friday January 02, 2015 @04:59AM (#48715337)

      Basically the article assumes that everything the PHP team puts out is "insecure" and that Linux distributors have some magic pixie dust that makes it "secure".

      Both assumptions are wrong:

      - First, the latest version of PHP will fix all known security vulnerabilities and will be as secure as those patched by Linux distributors.
      - Second, just because a distribution "supports" a PHP version does not make it any more secure.

      Pure clickbait.

  • by Rufty ( 37223 ) on Tuesday December 30, 2014 @09:05PM (#48700963) Homepage
    22percent of PHP installs are secure???
  • Or, as a php dev would say, "Over 20% are secure. We're making progress, folks"
    • by Hognoxious ( 631665 ) on Wednesday December 31, 2014 @03:52AM (#48702843) Homepage Journal

      A php dev would probably say 32%.

    • by SpreadsheetGamer ( 3969463 ) on Wednesday December 31, 2014 @02:59PM (#48706511)
      Yep, *sigh* after reading the headline I came looking for a comment like this. I'm a web application developer (LAMP stack and C# .NET MVC depending on where I'm working). In my experience, the kind of people who dis PHP fall in to two categories: generally ignorant or jealous of its success (often former java programmers). I'll address the ignorance: (It is amusing that you blame developers for what in any professional setting is the responsibility of a sysadmin, but that's an aside.) PHP is an astoundingly easy language to learn. It has among the best (if not *the* best) documentation of any language. It is hugely successful (80% of the top 10 million web servers according to the site referenced in the article above). In such a setting we will find /too many/ amateur web site authors who "just need" one simple thing which requires server-side scripting. They're not developers. They're barely web designers. They're often semi-technical people who got roped in to "doing a website" for someone's startup. I know this from reading hundreds of comments, threads, posts and help articles where the developer in question clearly has such a poor understanding of what they're doing - and they often know that themselves but just have to "get it done". I find it frustrating when PHP in general and the skills of PHP developers is judged on the average of all those who have ever dabbled with PHP.
  • ircmaxell (Score:5, Insightful)

    by TheNinjaroach ( 878876 ) on Tuesday December 30, 2014 @09:09PM (#48700995)
    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.
  • by Anonymous Coward on Tuesday December 30, 2014 @09:13PM (#48701027)

    It's hard to keep up with all the security advisories. It's hard to keep up with rebuilding from source. It's hard to use an ancient version shipped with Linux distros. It's a no win situation.

    People complain about Java and .NET updates, but let's face it, PHP has a lot of security issues too. I don't like Python, but I see less updates from them. It would be interesting to see what is the most secure install base for a language. It's probably hard to tell because some vendors are better than others about patching things.

  • by gbjbaanb ( 229885 ) on Tuesday December 30, 2014 @09:14PM (#48701031)

    to assume every web server is hacked already.

    Seriously, if you assume this, and code your way in a more secure, 3-tier manner, with a separate, and secured, application server, then you will mitigate all the problems with an insecure web server - well, at least they won't have full unfettered access to your database.

    This may mean giving up those "all in one" frameworks people so love (whether its PHP or .NET or any other language), but that can only be a good thing - write an app server with a secure API isn't so hard to do, but will mean your CEO won't have to appear on the news explaining why every user of his site needs to change their password and replace their credit cards.

    • by binarylarry ( 1338699 ) on Tuesday December 30, 2014 @09:18PM (#48701053)

      Apparently gbjbaanb has never heard of a man in the middle attack.

    • Seriously, if you assume this, and code your way in a more secure, 3-tier manner, with a separate, and secured, application server, then you will mitigate all the problems with an insecure web server

      For PHP web applications that aren't yet quite popular enough to need even a single dedicated server, is there a way to see some of the benefits of "a separate, and secured, application server" without tripling the budget?

      • by Anonymous Coward on Wednesday December 31, 2014 @12:05AM (#48701899)

        Use a jail?

      • by gbjbaanb ( 229885 ) on Wednesday December 31, 2014 @10:08AM (#48704169)

        Depends - if you're running on a shared webhost for $5 then you'll have more issues than cost to deal with - reliability and performance for instance.

        But you don't need full-on dedicated servers where the DB is completely disconnected from the web server, if you are just trying to mitigate the issue of an insecure front-end, then simply running the rest of the system secured from each other with different user accounts and a application layer running as a service (written n something else) will provide you with some benefit. Obviously it won;t help if the attacker gets root access to the underlying OS as then you're screwed, but it'd be a start.

        You need to ensure that your web site doesn't have access to your DB or other critical resources. If the attacker can gain access to your web server, then all he can do is call the same API you expose to the website, which often will do just what is needed (ie will not let you download every cc number, or see any critical data like cc or password at all)

        But overall, if you can afford $5 for a website, you are not storing anything critical at all. If you're paying more your site is important enough to pay the extra for security. You could still have a couple of $5 websites for the front end and then run the rest on a more serious VPS setup that is better secured, that's not going to break the bank.

      • by RavenLrD20k ( 311488 ) on Wednesday December 31, 2014 @03:01PM (#48706527) Journal
        Depends on how big your initial budget is. If you're running PHP web apps that are so lightly hit that you can't warrant provisioning a dedicated server instance or PC for them, use a Pi or BeagleBone or similar low powered/cheap option. If you're getting more traffic than 2 or three BB's in a cluster can handle, maybe you should look into a cheap VPS. There are some that provide more than enough power to run a site for less than $10/mo per instance. For my own low end hobby needs a basic VPS at Centarra [centarra.com] for the front end and a cluster of 3 BeagleBone Blacks with a self-modified version of CentOS running the back end at my house has served me well for as much time as I have to put into it (mostly used for OwnCloud file storage so I can get around anti-thumbdrive policies when I'm out and about). All total runs me about $8/mo for the instance, $19/yr for the domain, and I don't count the Bones because they're paid for and the power and bandwidth requirements are both miniscule as well as incidental (need the electricity and internet at the house anyway).
        • the power and bandwidth requirements are both miniscule as well as incidental (need the electricity and internet at the house anyway).

          Unless your ISP doesn't let you run a web server at home. Some ISPs threaten to disconnect residential customers that receive a large amount of inbound traffic. Other ISPs, especially those using a microwave last mile (such as cellular or satellite) and those in areas hit hardest by the IPv4 address shortage, put their users behind a carrier-grade NAT and don't forward ports to subscribers. And even if they did forward non-well-known ports, alternate ports confuse end users because HTTPS and HTTP user agents are currently hardcoded to use ports 443 and 80 rather than getting port numbers from the SRV record at _http._tcp.example.com.

          • by RavenLrD20k ( 311488 ) on Wednesday December 31, 2014 @10:54PM (#48709439) Journal
            Who's running a web server at home? Granted my ISP provides me with full incoming and outgoing capability without blocking ports, provided I don't break my bandwidth limits... my bones are not running web servers; 2 are running as NAS serving through ssh and one is a MaraDB server with port forwarding handled by the Cisco Router provided by Cox. The bone running MaraDB also checks the public IP twice a day and will forward an email to me if it changes so I can go into Centarra (who's also running my DNS zone) and update the A record that points home. Centarra also provides APIs where I could set this up to be completely automated, but I haven't had the time to implement it (compared to the rest of the set-up, this would be relatively trivial). The web server is on my Centarra Instance out in the cloud, and it's making the direct calls to the home network that run the apps that grab the data/files and sends it back to the web server that provides the transmission of the file back to the client. If I ever required faster speed / more traffic, it would be nothing for me to fire up a couple more instances for a total of $30/mo, but I'm not even close to pinging the radar with my current setup. I do admit, to set this up securely and efficiently an in-depth knowledge of Networking, System Administration, and Programming are highly recommended. As with most things in life the following statement applies: Cheap, Secure, Easy; pick 2.
    • by Anonymous Coward on Wednesday December 31, 2014 @05:02AM (#48703069)

      I'm curious about tools available to scan for vulnerabilities. I have several PHP-based webservers, and keep Linux/PHP/NginX/App up to date, but really have no idea if that's a false sense of security or not.

  • by Anonymous Coward on Tuesday December 30, 2014 @09:18PM (#48701055)

    'k, where the component is embedded inside something larger and THAT doesn't get updated, yes , developer. But then, OpenSource ?, are you paying the developer to create secure code ?. If not stop whining and keep track of the problems yourself.

    Non-updated deployed software though, seldom the developers 'fault' anyway, that's almost invariably a manager or site owner responsible for that mess.

  • PHP (Score:5, Insightful)

    by ledow ( 319597 ) on Tuesday December 30, 2014 @09:23PM (#48701079) Homepage

    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.

    • by Narcocide ( 102829 ) on Tuesday December 30, 2014 @09:48PM (#48701209) Homepage

      Seems like you put a lot of thought into this but you're frankly wrong. Wordpress didn't exist until years after "register globals" got deprecated. I agree it should never existed in the first place, but Wordpress is insecure entirely without any help from "register globals."

      • Re:PHP (Score:5, Informative)

        by ircmaxell ( 1117387 ) on Tuesday December 30, 2014 @10:04PM (#48701275) Homepage
        Ummm... No. WordPress was first written in PHP3. Before it was even called "register globals". Back when that was just how you did things.
        • by Yakasha ( 42321 ) on Wednesday December 31, 2014 @02:47PM (#48706389) Homepage

          Ummm... No. WordPress was first written in PHP3. Before it was even called "register globals". Back when that was just how you did things.

          Wordpress 0.7 was first released in 2003. Register globals was first disabled in PHP 4.2 in 2002. So, yes, register globals was deprecated (though it did not throw a warning until later) before Wordpress was released. As PHP 4.0 was released in 2000, a full 3 years before Wordpress, I even question the PHP3 claim (well, I question their reasoning for developing a new product on PHP 3).

          As a PHP developer at the time, I also dispute the claim that register globals was "just how you did things", in 2003.

          • by Yakasha ( 42321 ) on Wednesday December 31, 2014 @02:52PM (#48706443) Homepage

            As a PHP developer at the time, I also dispute the claim that register globals was "just how you did things", in 2003.

            Nah, thinking back some more... At least one job did still use PHP 3 in 2002... So, ya, I'll retract this statement. Many people did still use it, and 4.2.0...

      • Re:PHP (Score:3, Informative)

        by pspahn ( 1175617 ) on Tuesday December 30, 2014 @10:33PM (#48701407)

        Wordpress is widely adopted. Very widely. The #1 reason it is insecure is because it is targeted so often.

        Is that PHP's fault?

        Along with WP, plenty of other platforms plainly store their database credentials in some config file. It might be PHP, maybe XML, maybe JSON ... irrelevant. The credentials are stored in plaintext on the server.

        Is that PHP's fault?

        All these platforms do things in their own way. I'm a Magento developer and it is a platform that is notorious for it's complexity. I understand it pretty damn well, but the majority of the code I see was clearly written by folks who don't understand it very well. I've seen /www/var/log left wide open and the justification was that /www/var/log doesn't contain anything important. Just errors and stuff like that. For those paying attention, what's the difference between Mage::log($order, null, 'orders.log') and Mage::log($order->debug(), null, 'orders.log')? If you said, "the first one will log the entire object -- including database credentials", you get a cookie.

        I'm talking about Magento specifically there, but every platform has it's own thing and twists PHP into doing things a bit differently. This fragments the understanding of the code and results in company XYZ hiring a "PHP developer" when they should have hired "Platform X developer".

        I am wary of the statistics presented by this article simply because they don't take into account platform insecurities and the plethora of code that was written with a lack of full understanding. The number of "insecure" PHP sites is probably much closer to 100% than advertised, but it usually isn't PHP's fault.

        • Re:PHP (Score:4, Insightful)

          by dgatwood ( 11270 ) on Tuesday December 30, 2014 @11:42PM (#48701791) Homepage Journal
          Wordpress is widely adopted. Very widely. The #1 reason it is insecure is because it is targeted so often.

          No, the #1 reason it is insecure is that it isn't secure. The #1 reason it looks insecure is because it is targeted so often.

          Along with WP, plenty of other platforms plainly store their database credentials in some config file. It might be PHP, maybe XML, maybe JSON ... irrelevant. The credentials are stored in plaintext on the server.

          There's nothing wrong with doing that. The database shouldn't be accessible from arbitrary machines anyway, so having the credentials buys an attacker nothing. Besides, how the heck else are you going to provide credentials to a script? No, the real problems are that:

          • Many servers are misconfigured so that any Tom, Dick, or Harry can access the database and wreak havoc after they manage to steal those credentials.
          • Many web servers are misconfigured so that it isn't possible to allow the script to access those config files without allowing other unrelated users to access them.
          • Many shared web servers are misconfigured in ways that allow PHP scripts owned by other users to access those same files, with no way to prevent that access.

          All of these fall under the category of sysadmin configuration mistakes, not flaws in the software, per se, though in some cases, the software may create files with poor permissions (or in an insecure way, allowing for race condition attacks) that exacerbate those problems.

          All these platforms do things in their own way. I'm a Magento developer and it is a platform that is notorious for it's complexity. I understand it pretty damn well, but the majority of the code I see was clearly written by folks who don't understand it very well. I've seen /www/var/log left wide open and the justification was that /www/var/log doesn't contain anything important. Just errors and stuff like that. For those paying attention, what's the difference between Mage::log($order, null, 'orders.log') and Mage::log($order->debug(), null, 'orders.log')? If you said, "the first one will log the entire object -- including database credentials", you get a cookie.

          To some degree, that points to the need for both better logging systems and better back-end software design. When I'm writing code, I'm very careful to explicitly have separate debug levels, with explicit comments about the security or insecurity of each of those levels. Those security-risky debug levels are turned on only for short periods of time while fixing authentication-related bugs, and any secret info goes into a separate log file in a location outside the web root so that you can't trivially access it by making requests to the server itself—and never to a syslog daemon (whose log files are potentially readable by other users on shared hosting systems).

          I also segregate user credentials into separate objects/variables. With the exception of the numeric user ID itself, none of that info is ever used outside of my authentication and authorization code, which is segregated into separate files to avoid accidental disclosure. Thus, none of the authentication information ever appears in any object that could realistically get logged. The obvious exceptions are objects associated with the database, which ostensibly contain database auth information, but I'm never going to print_r a database connection object (assuming that's even possible), so that's mostly moot.

          The number of "insecure" PHP sites is probably much closer to 100% than advertised, but it usually isn't PHP's fault.

          Actually, it is probably much lower, for several reasons:

          • OS X v10.9 gets regular security updates, and ships with a version lower than the version they list. However, Apple routinely patches the software that they ship (rather than updating it) when security vulnerab
        • by Anonymous Coward on Wednesday December 31, 2014 @05:25AM (#48703183)

          The credentials are stored in plaintext on the server.

          Yes, the USER credentials to their own DB. If you store root in there, even encrypted, then you are the problem.

          You have the data to a DB user account? Great! This server is not running security through obscurity.

    • Re: PHP (Score:2, Interesting)

      by Anonymous Coward on Tuesday December 30, 2014 @10:31PM (#48701395)

      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.

      • Re: PHP (Score:2, Interesting)

        by Anonymous Coward on Wednesday December 31, 2014 @03:51AM (#48702839)

        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.

        • by Anonymous Coward on Saturday January 03, 2015 @01:33PM (#48725485)

          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.

          Why would someone with zero tests day they have nearly complete test coverage? And why would anyone just throw up their hands, say "testing is impossible," and just implement straight to production? You sound like a PHP developer who is the cause of the problem.

    • Re:PHP (Score:5, Insightful)

      by Trane Francks ( 10459 ) <trane@tranefrancks.com> on Tuesday December 30, 2014 @11:55PM (#48701857)

      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.

    • by Tablizer ( 95088 ) on Wednesday December 31, 2014 @01:06AM (#48702155) Journal

      Why aren't there "long-term support versions" similar to what Ubuntu offers? Only security flaws are patched in such versions. However, I realize patching security flaws can break existing software also, but if you only patch security flaws rather than add and change features for the line, the magnitude of problems from updates would be smaller.

      • by kthreadd ( 1558445 ) on Wednesday December 31, 2014 @02:38PM (#48706331)

        Why aren't there "long-term support versions" similar to what Ubuntu offers? Only security flaws are patched in such versions.

        Ubuntu only supports a handful of packages, specifically those in the main and restricted sections of the package archive. This includes the main php5 package but a large number of modules are kept in universe and are not supported at all.

        However, I realize patching security flaws can break existing software also, but if you only patch security flaws rather than add and change features for the line, the magnitude of problems from updates would be smaller.

        It depends on the vulnerability. I had things break when the bash vulnerability was patched some time ago. There is no solution other than test that things work before you apply the update.

        • by Tablizer ( 95088 ) on Saturday January 03, 2015 @04:22AM (#48723525) Journal

          I meant Ubuntu LTS distro's directly (as an example), not Php in their distros.

          And while I agree that security patches will probably always break some stuff, it's still the lessor evil compared to full upgrades (features & security).

    • by AcerbusNoir ( 1257586 ) on Wednesday December 31, 2014 @02:21AM (#48702513)
      <quote>Because upgrading PHP breaks shit.</quote>

      Like upgrading from Python v2 to v3?
      • by OutOnARock ( 935713 ) on Wednesday December 31, 2014 @03:41PM (#48706893)


        No. It was announced loud and clear that going from Python 2.x to 3.x would require changes.

        I never had a problem with Python 2.x -> Python 2.x or Python 3.x -> Python 3.x

        you PHP shills just don't get how bad PHP sucks balls.
    • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Wednesday December 31, 2014 @07:35AM (#48703571) Homepage Journal

      Every web host I've ever used, personally or professionally, will give you a version of PHP and rarely update it.

      And every web host I've ever used long enough to notice has updated PHP and then you have to go into cPanel to change the version you're using. Perhaps your hosting companies were doing the same, and you simply failed to notice.

  • by Narcocide ( 102829 ) on Tuesday December 30, 2014 @09:24PM (#48701081) Homepage

    PHP coder since before 4.x. All the bad stuff started happening when people started using redistributed PHP frameworks.

    • by pspahn ( 1175617 ) on Tuesday December 30, 2014 @11:25PM (#48701675)

      Do you imply that redistributed PHP frameworks are the problem. In 2015, do you have some alternative suggestions?

      I feel like you're saying it would be a great thing if everyone went back to CFML, because you know, hey, it's great having to pay for all your software tools. Of course freely distributed software is going to cause "bad stuff" to happen. I'm pretty sure licensed software isn't immune, either, it's just a different flavor of "bad stuff".

      You make a great point, don't get me wrong, it's just that you left it hanging too low. What if we want to have our cake and eat it too? Where does the guy go who thinks, "yeah, I'm totally gonna put all of PHP's crap on the lawn, I don't care if they're paying rent"? In 2015, if I want to build software based on distributed frameworks but I want to do it without any "bad stuff", where do I go?

      Javascript/Node? But then I get stereotyped as a fucking douchebag hipster that couldn't code my way out of Prius. I classify that as "bad stuff".

      Python? Then I get to be the guy that's always talking but nobody listens. Also "bad stuff".

      ASP.NET? Oh ... right. If this is the answer I'm moving up to the mountains to grow pot and fish for trout. Full time.

      Meanwhile, back in "work week" land, I'll head back to the office tomorrow and start chugging away on PHP built on a distributed framework with tons of "bad stuff". I will use the money I earn from this job to do tons of other "bad stuff" like, you know, pay bills, buy food, grow pot, fish for trout .. etc.

      • by Richard_at_work ( 517087 ) on Wednesday December 31, 2014 @07:28AM (#48703549)

        You realise there are loads of us who spend our time in "work week land" happily getting on with shit using .Net, ASP.Net MVC and other .Net frameworks (I currently heavily use NancyFX) and earn money while having a great time doing it? And up until 2008 I was a full time PHP developer, but you won't ever see me going back to PHP now, its just not worth putting myself through that pain and suffering.

        So, dismissing ASP.Net out of hand, seemingly simply because you dont like it, limits your options for no good reason.

  • by grub ( 11606 ) on Tuesday December 30, 2014 @09:26PM (#48701101) Journal

    I guess the Perl-loving neckbeards at /. were right all along.
  • by Anonymous Coward on Tuesday December 30, 2014 @09:38PM (#48701175)

    He's purely going off minor versions, eg 5.5.9 for Ubuntu. This test doesn't care whether there's backports or revisions like 5.5.9-0 vs 5.5.9-1 vs 5.5.9-1-U45
    It'd be just as effective as counting insecure versions of IE, regardless of whether it's running on WindowsRT, Windows 7 or Windows XP.

    There's also no mention that the versions lasted as "without known bugs" may be running shite software... *cough*WordPress*cough*

    While ircmaxwell has been helpful in the past, I'd think more useful tests would be the existence of info.php or phpinfo.php files in the usual locations, or webhosts running PHP that have also been blacklisted for spam or infections in the last 3 months.

  • by AchilleTalon ( 540925 ) on Tuesday December 30, 2014 @09:49PM (#48701211) Homepage

    If someone can explain, I don't understand why he is mapping to Linux distros. The W3Techs.com site just give the distribution of various versions of PHP and the percentage of these. I just did a spreadsheet using only the numbers from W3Techs.com and I am getting something like: 27.1% secure and 72.9% unsecure. Not that is a big difference, however it evades me why he is mapping everything to a Linux distro given many distros are missing in his analysis. Any hints?

    • Re:Why the distros? (Score:5, Informative)

      by ircmaxell ( 1117387 ) on Tuesday December 30, 2014 @10:07PM (#48701287) Homepage
      The point most people make when you talk about running old versions is that "well, distributions backport security fixes, so 5.3.3 is secure on distro XYZ".

      So, to get around that, I looked at the popular distro's versions that they maintain. Then I counted *all* of those point versions as secure (over counting). So 5.3.3 is insecure as distributed by php.net, but as installed by Debian 6 it is secure.

      So therefore to get an upper bound (rather than lower bound) on secure versions, you need some way of factoring in for distro support.

      So I picked the most popular distros for server usage. Is this hand-waving? Absolutely. But it should give a pretty reasonable upper-bound.
      • by AchilleTalon ( 540925 ) on Tuesday December 30, 2014 @10:31PM (#48701393) Homepage
        Ah! Thanks for the clarification.
      • by Chuck Chunder ( 21021 ) on Wednesday December 31, 2014 @01:26AM (#48702241) Journal

        "well, distributions backport security fixes, so 5.3.3 is secure on distro XYZ".

        Are you aware of any analysis as to the extent that is actually true, ie for distro X or Y which patches really have been backported and which are skipped?

        I had a quick poke about the W3Tech site and couldn't really see much of their methodology, especially in terms of how they identify PHP usage and what version is being used. I'd have though that if you looked at their PHP page [w3techs.com] there should be a not insignificant number where they can reasonably guess it's using PHP (due to file extensions in URLs perhaps) but not be able to identify the version being used.

        I wonder how much your "% of installs that are secure" statistic could be inaccurate due to most (I'd hope) sites that care even slightly about security suppressing the Apache header PHP version information. Are they just missing from the W3Tech stats? It's possible that a significant number of the "secure" PHP installs could be invisible to your calculations because the sort of people who keep their software up to date are the same people who follow fairly basic server set up recommendations.

        I suppose there are also questions as to what "insecure" means in practice. For bulk hosting sites running unknown third party code everything is critical but for a lot of sites running their own code whether they are actually "insecure" depends not only on what PHP does but also what their code does. Eg for the most recent PHP 5.4 release [php.net] there is a fix for a fairly nasty looking bug in unserialize(), but (as I understand it) a site admin with a defined codebase might quite legitimately determine that they never use unserialize() on user generated data and not be in any rush to update if they have other things to be doing. PHP version 5.4.35 might be "insecure" for the purposes of your stats but may not be in practice someone's server if they know they don't use unserialize() in an exploitable fashion (or mcrypt).

        None of the above should be interpreted as criticism of your analysis, just food for thought. I find what you have done very interesting and expect that even if there are 'hidden' secure servers, the number of insecure ones would still be alarmingly high.

        • by ircmaxell ( 1117387 ) on Wednesday December 31, 2014 @12:17PM (#48705069) Homepage

          Are you aware of any analysis as to the extent that is actually true, ie for distro X or Y which patches really have been backported and which are skipped?

          Yes. For most CVEs, the major distributions do backport fixes. They don't however backport all security fixes.

          For example, there was a bug in crypt's bcrypt implementation which would cause collisions for certain classes of passwords (specifically those with characters with high bits set). The fix in 5.3.6 was to add a check into the normal $2a$ implementation, and to add $2x$ (legacy) and $2y$ (proper implementation). So when using > 5.3.6, you can enforce proper behavior using $2y prefix to crypt. CentOS backported this into their 5.3.3 version. Debian did not. So from a security standpoint, we now how a divergence between the two.

          I wonder how much your "% of installs that are secure" statistic could be inaccurate due to most (I'd hope) sites that care even slightly about security suppressing the Apache header PHP version information.

          Absolutely. The analysis is only as good as its data source. There are other people looking at other data sources (httparchive for one) to try to get more data for it. But ultimately I had to go with what I had.

          I suppose there are also questions as to what "insecure" means in practice.

          Well, perhaps insecure is an extremely misleading term in this context. Vulnerable would be better. Yes, an attack vector may not exist, but the vulnerability does. The reason this is important is that today you may not be using unserialize() on user input, but that doesn't say you won't tomorrow. The hole will exist, the vector would be what's created.

          Check out my slight elaboration on this in this comment [slashdot.org]

    • by tshawkins ( 1239974 ) on Tuesday December 30, 2014 @10:11PM (#48701303)
      I think he is trying to show that the distros are doing a poor job in ensuring that insecure versions are not getting frozen in thier distributions.
  • by Anonymous Coward on Tuesday December 30, 2014 @10:12PM (#48701307)
  • by JohnVanVliet ( 945577 ) on Tuesday December 30, 2014 @10:26PM (#48701363) Homepage

    not surprising at all
    over at LinuxQuestions we had a rash of

    H E L P ! ! !
    I just installed RHEL6.0 ( unlicensed !!!)
    i just installed Fedora 12 ,or 13,or14 ( fedora 21 is current)

    and !! NO KIDDING !!!
    i just installed RH7.2 ( the rh7.2 from 1996 )
    and
    i just installed RH9 ( from 2001 )
    and a few
    "i just installed RHEL4.0 " ( RHEL 7.0 is current)

    and this was only in the redhat family

    • by Gavagai80 ( 1275204 ) on Wednesday December 31, 2014 @03:01AM (#48702661) Homepage

      Time traveler problems.

    • by creepynut ( 933825 ) <teddy(slashdot) AT teddybrown DOT ca> on Wednesday December 31, 2014 @08:26AM (#48703745) Homepage

      I'd wager a lot of it is school assignments. School courses are rarely kept up to date with the current distros. I can't blame them for not keeping up with the latest Fedoras, but at least they should be running a supported enterprise release (i.e. RHEL6, but encourage them to use CentOS).

      I see a lot of the "I am trying to install Fedora 10 but it won't work". Of course it's normally because the package repositories have been archived and the default install can't find them. When asked why they are using such an old version some people come clean and say it's for school, or say it's a "requirement".

    • by ihtoit ( 3393327 ) on Wednesday December 31, 2014 @09:20AM (#48703935)

      I just installed OpenSUSE 13.2 on a VM with 2GB RAM assigned, installed using the network image. EVERYTHING worked. I mean EVERYTHING. All my devices, mapped shares, the lot.

      The fuck did I do wrong?? Usually when I install $NT, I have to spend the next six hours dicking around with system updates, device drivers and application licence keys.

  • by Required Snark ( 1702878 ) on Tuesday December 30, 2014 @10:29PM (#48701379)
    Given how abysmal PHP is as a language, it seems completely consistent that an overwhelming percentage of the deployed systems are security failures. PHP seems to breed incompetence.
  • by mveloso ( 325617 ) on Tuesday December 30, 2014 @10:31PM (#48701389)

    What he's saying is that the only "secure" version of something is x.x, x.y, z.x. Anything else is "insecure."

    Well fuck, what about all those XP installations? Default apache configs? Systems using heartbleed SSL? What about if they're hosted on platforms that aren't current? What about embedded platforms?

    Basically, 99% of the internet is insecure.

    I mean, come on: 82.27% of perl installs are secure? 77.59% of python installs? Get real.

    • by ircmaxell ( 1117387 ) on Tuesday December 30, 2014 @10:37PM (#48701421) Homepage

      I mean, come on: 82.27% of perl installs are secure? 77.59% of python installs? Get real.

      No. 82.27% of all PERL installs have no known vulnerabilities in PERL itself.

      This isn't to say the code on top is secure. And it isn't saying that it's exploitable. Just whether known vulnerabilities in the platform itself exist.

      • by account_deleted ( 4530225 ) on Tuesday December 30, 2014 @10:46PM (#48701475)
        Comment removed based on user account deletion
        • Re:Bogosity (Score:4, Interesting)

          by ircmaxell ( 1117387 ) on Tuesday December 30, 2014 @10:56PM (#48701533) Homepage
          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.

  • by lucm ( 889690 ) on Tuesday December 30, 2014 @10:40PM (#48701449)

    I just deployed a secure PHP install for my new blog. Please adjust the numbers to reflect this since those numbers are allegedly for all installs.

  • by Charliemopps ( 1157495 ) on Tuesday December 30, 2014 @11:04PM (#48701577)

    And who cares?
    I don't have anything that requires security or matters in PHP. I never would, it's just kind of a crappy scripting language to me.
    I've PHP that does "Stuff" but none of it is handling private data or writing to databases. At best it's manipulating the data after it's arrived locally and displaying it. Or manipulating it in a form or something before delivering it. I supose it could alter the users intent on send, but I don't care. I'd treat them as untrusted anyways, they're just as likely to be bad actors as some hacker... My users aren't using PHP to login, connect to APIs or anything else that matters... How many people actually use PHP to do anything sensitive? Really, tell me, I don't know. I live in my own microcosm of code so I'm interested if this is a real problem or not.

  • Our company runs our own servers; we run Ubuntu Linux. Our web sites are PHP. All I know is to run apt-get every Sunday and Ubuntu can update whatever it wants to. These are in-company web sites with login user names and passwords. No e-commerce involved; no public involved.

    Am I a security export? Hell no. I've been programming for 45 years. My first language was FORTRAN; my first "personal computer" was a 360/20.. If it takes a security expert to code a program today than our industry is fundamentally flawed.

    • by Anonymous Coward on Wednesday December 31, 2014 @04:58AM (#48703055)

      Am I a security [expert]? Hell no. I've been programming for 45 years. My first language was FORTRAN; my first "personal computer" was a 360/20.. If it takes a security expert to code a program today than our industry is fundamentally flawed.

      Or it could be that what is being called for is not a "security expert" but a "security minded" programmer who takes consideration for error cases. Most programs developed in-company are crap because it's presumed that everything is done internally by interlocking programs, by well-enough sanitized interfaces, and/or with the notion that any damage will be traceable to an employee that can be punished. Well, all that really goes out the window when you put something on the internet, and honestly the audit trail for most businesses is horrible enough that in-company design risks all sort of damage that is not fixable* nor will anyone be held responsible (except perhaps the original IT guy).

      Really, though, programming naturally requires a certain property of correctness to give good results and by its very nature should be written with correctness in mind that would thrawt most security threats. Unfortunately, there's not enough real engineering or design that often goes into it and the result is people who "apt-get every Sunday and [let the OS vendor] update whatever it wants to" without regard to how much of a mess Monday can be when it's deployment without adequate testing. Of course, when it's a small enough company, perhaps the overtime or losses for one missed day of work for the company makes up for all the constant costs of security up to that point, but preventive care is almost always cheaper even in those isolated cases.

      * As above, it might not matter. Payroll records might be destroyed, but you can stitch together enough of what was and will be through most workers or the bank. Same with most orders or customer complaints or whatever. If there's not a paper trail, there's most often several copies in various places and enough information can be rebuilt with the less important stuff lost. Of course, once you start including an actually malicious element, the situation can radically change. But, that doesn't seem to matter to you.

    • by kthreadd ( 1558445 ) on Wednesday December 31, 2014 @02:45PM (#48706377)

      Our company runs our own servers; we run Ubuntu Linux. Our web sites are PHP. All I know is to run apt-get every Sunday and Ubuntu can update whatever it wants to. These are in-company web sites with login user names and passwords. No e-commerce involved; no public involved.

      In case you ever run a public Ubuntu-based server make sure that you never install packages from the universe or multiverse components of the package archive. They are not updated by the Ubuntu security team and can therefore include unpatched vulnerabilities, which include a large number of php5 packages.

  • by CODiNE ( 27417 ) on Tuesday December 30, 2014 @11:08PM (#48701591) Homepage

    Why is it that 5.3.10 is listed as the last secure PHP 5.3 when there's many more releases after it?

  • by portiakingx ( 3968793 ) on Tuesday December 30, 2014 @11:38PM (#48701757) Homepage
    since most people use web hosting companies some who take time to update their servers there needs to be a dedicated campaign focusing on these guys to shape up.
  • by Anonymous Coward on Wednesday December 31, 2014 @12:09AM (#48701917)

    "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. "

    That cuts both ways. One of the reasons that people install from source is so as to get a more secure version. So even if the distribution is using an insecure version, some people may still be running a secure version. I shudder to think about what he'd make of Gentoo or a BSD variant using ports.

    You could just as well argue that this number is a *lower* bound. Since there are more people in the insecure distribution bucket than the secure bucket, the same error rate for both would increase security. Of course, there are a couple reasons why the secure to insecure transition may be more common than the insecure to secure.

    My main point is that it is all too easy to use statistics to argue a point of view. If you then massage the statistics further to reinforce your beliefs, chances are that you are doing something wrong. Don't do that.

  • by Anonymous Coward on Wednesday December 31, 2014 @12:48AM (#48702083)

    Get rid of it. Of PHP. Bite the bullet, see through the sunk cost fallacy, and learn a less broken language for a change.

    But of course you won't. You're still using windows, for eerily similar reasons, aren't you?

  • by Anonymous Coward on Wednesday December 31, 2014 @01:23AM (#48702225)

    I have a full software stack that I maintain (website). For the whole thing, I compile code. The operating system, PHP, Mariadb, Apache Web server, Wordpress. But not just that, to support those applications, I add more software: a lot more software: apr-1.5.1, apr-util-1.5.4, curl-7.39.0, fftw-3.3.4, freetype-2.5.4, gd-2.0.35, gmp-6.0.0, ImageMagick-6.9.0-1, lcms2-2.6, libevent-2.0.21-stable, libmcrypt-2.5.8, libmemcached-1.0.18, libpng-1.6.16, libtool-2.4.4, libxml2-2.9.2, libxslt-1.1.28, lua-5.2.3, mcrypt-2.6.8, memcached-1.4.21, mhash-0.9.9.9, modsecurity-apache_2.7.7, openssl-1.0.1j, pcre-8.3.6, re2c-0.13.7.5, and t1lib-5.1.2. And I just finished updating everything a few days ago. And 1) I maintain all support files to be shared object (.so) files for greater scalability, I can "drop" new versions in and have my build scripts automagically accept the new source blob, decompress it, and build it, and it also builds the PHP/Apache/Mariadb/Wordpress stacks and configures everything (as a single piece, it builds the lot of it on a quad-core processor with nothing else running in about 40 minutes). Now I'm just a lone developer. How is it that large scale sites can't do what I've done when they have teams of people supposedly knowing what they are doing? I also run website and database snapshots to a NAS once per week (I wrote scripts to do that too). Occasionally the new software doesn't work ok (bugs introduced and not fixed for several versions), but it doesn't happen often, and you can always revert to the older version of the software and take your time debugging the new stuff (apply patches as needed).

  • by Anonymous Coward on Wednesday December 31, 2014 @03:24AM (#48702753)

    This article seems a little mindless. Just as talking about a PHP install as being secure or not, as if that is even a big enough part of the system to consider on its own. What about, like EVERYTHING else? Minimal OS, thought out firewall incoming and OUTGOING rules, build from source not because it is more secure, but because building from source means you KNOW WHAT THE FUCK is in your stack. Like first rule of thumb on any web facing tool, build with the latest version of openSSL, unlike most OS dist will have done. My own pitiful list of a few notes here already goes way beyond TFA which shows how sad it really is. Goofball stats for people who are hopelessly lost already, great thanks guy.

  • by Mark Hunting ( 3969295 ) on Wednesday December 31, 2014 @09:58AM (#48704121)
    On lots of servers the version number is hidden, so they can't be included in these statistics. My guess is that administrators who know that the version number should be hidden on a production server also update PHP more (or automatically). In that case the conclusion of this post is very doubtful.
  • by plopez ( 54068 ) on Wednesday December 31, 2014 @11:59AM (#48704925) Journal

    I have never heard of a developer held responsible for failures. EEs, CivEs, ChemsEs, etc have to carry malpractice insurance to work.Until they can be sued and held responsible they will not be responsible.

    That is why Software Engineering, IMO, does not exist. At best developers are skilled workers but not engineers.

  • by MoarSauce123 ( 3641185 ) on Thursday January 01, 2015 @03:59PM (#48712697)
    The problem is that PHP is just one piece in the entire stack. Updating PHP will often require fixing the ini file. Updating the web server will require fixing the web server config files. Updating the database might require fixing PHP's ini and fixing the database config. And if there are any other parts in the mix it will be even worse. What is missing is a simple means to update the entire stack and transfer the customizations in the configuration files. Even experts like Apachefriends all but abandoned the option of upgrades. What the XAMPP stacks are missing is a unified and simple patch/update procedure. The other stacks are not any better as far as security goes, but it is a heckuva lot easier to update/patch IIS/ASP/MSSQL...often on a monthly basis. As soon as folks can't be lazy they tend to not do the necessary work. Make patching XAMPP easier and the problems with unsecure installs will go down.
  • by MoarSauce123 ( 3641185 ) on Thursday January 01, 2015 @04:06PM (#48712721)
    WordPress and Drupal are listed separately...as if both are not using PHP! Looks as if someone cooked up the stats just to blame PHP. I don't get why PHP is always used as whipping boy often using bogus arguments.

God doesn't play dice. -- Albert Einstein

Working...