Slashdot Mirror
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.
Well, some therapy should help them overcome their insecurities!
22percent of PHP installs are secure???
Red to red, black to black. Switch it on, but stand well back.
Or, as a php dev would say, "Over 20% are secure. We're making progress, folks"
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
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.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
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.
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.
'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.
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.
PHP coder since before 4.x. All the bad stuff started happening when people started using redistributed PHP frameworks.
I guess the Perl-loving neckbeards at
Trolling is a art,
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.
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?
Achille Talon
Hop!
Student Suspended Over Suspected Use of PHP
not surprising at all
over at LinuxQuestions we had a rash of
H E L P ! ! ! ,or 13,or14 ( fedora 21 is current)
I just installed RHEL6.0 ( unlicensed !!!)
i just installed Fedora 12
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
"I don't pitch OpenSUSE Linux to my friends, i let Microsoft do it for me
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.
Why is Snark Required?
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.
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?
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.
lucm, indeed.
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.
Why is it that 5.3.10 is listed as the last secure PHP 5.3 when there's many more releases after it?
Cwm, fjord-bank glyphs vext quiz
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.
"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.
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?
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).
You must be programming in GOML++
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.
See subject line. It's like saying, "78% of sites running a web server on WIndows ME are insecure." Well really?
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.
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.
putting the 'B' in LGBTQ+
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.
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.
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.