Well now that some of you have met me from OSCON, you are probably thinking to yourself, “What’s the deal with your blog? There is no PHP in there, you poser.”
I think that when most people hear “PHP” and “security” used in the same sentence, it seems about as out-of-place as, say, putting “Rasmus” and “Terry” in the same sentence. Basically this thread summarizes how most people view PHP security.
I suppose the first thing I need to do in order to defend the honor of PHP is say that these losers have their own agenda: foisting Java or dotNet as “real” and “enterprise”2, or perhaps they’re just sore because PHP book sales are going up at their expense.
Nothing works better than a good ad hominem, I always say.
Well I suppose for the three of you left unsatisfied with my deconstruction, I should go through the tedious task of addressing the actual complaint which boils down to:
- “PHP has the worst security history of any language.”
- “PHP shoves a mess of shit into the global namespace” (or other assorted digs on register globals).
- “PHP doesn’t have the concept of a prepared statement.”
- “PHP security cures (magic quotes, safe mode, stripslashes) are sometimes worse than the disease.”
Let’s address these one by one.
“PHP has the worst security history of any language.”
This statement is possibly false, but it is always best to speak in absolutes on Slashdot. (Qualifications and honesty might make you appear rational and you wouldn’t want to stand out.) Ilia explained this complaint to me at the OpenSolaris party (now admittedly, I had a bit to drink, but I was trying to sober up enough to drive back). Basically this argument boils down to defining security with the spurious metric of counting the number PHP exploits on BugTraq.
Normally, I’d use the “Microsoft defense”: invoke Metcalfe’s Law, point out that PHP is the #1 web application server by a large margin, and then conclude, “therefore, of course, PHP has the most security holes, because nobody is using anything else and all those ‘evildoers’ are targeting PHP,” just before driving home in my Ferrari to take a nice swim in my piles of ill-gotten cash. The only problem with this defense is I don’t have a Ferrari or piles of cash, ill-gotten or otherwise. (Well, I suppose another problem is that Metcalfe’s law is bullshit.)
So I’ll resort to Ilia’s explanation (in two points). First there are a lot of projects with “PHP” in their name that have nothing to do with the PHP Group: phpMyAdmin, phpBB, etc. They’ve been sent cease-and-desist but there is no enforcement. Nearly every BugTraq entry is with some application like that and PHP suffers a guilt by association.
Second, PHP is known by some of its applications. If you see a large project written in PHP, there is an assumption on the part of IT managers that because it is popular it must be secure and its programmers are competent. But in reality, PHP projects operate by a different dynamic in which good code is uncorrelated with popularity.
You merge these two and you end up with a project like phpBB with so many security holes that it is laughable, and most of those are regressions from previous security patches. Then they go around blaming the PHP language for their own incompetence.
(The silver lining here is that phpBB makes a nice straw man for Ilia to push FUDForum and sell security support contracts. “Point me to your phpBB install, and I’ll have forum administration access in 15 minutes.”)
“PHP shoves a mess of shit into the global namespace.”
Spoken like someone who knows nothing about PHP. PHP has no globals in any space besides a few reserved “superglobals”. All other globals have to be explicitly declared into the scope in order to be used. That plus the “$” delimiter for variables means that you can poo all over your global namespace without fear.
Do these other languages do this? No, they resort to silly conventions such as Hungarian Notation and Singleton patterns in order to do this.
It is true that in the past PHP had register_globals. This was turned off by default with PHP 4.2 and caused one of the worst growing pains in PHP history. Why? Imagine yourself running a script you or someone else wrote that depends on this “feature” in a hosted environment. Then your host upgraded to PHP 4.2 without informing you. All of a sudden, you are losing business and you don’t know why. It sucked!
Yeah, well what could they have done? register_globals was a disaster left over from a kinder, gentler WWW. I’m glad they turned if off, if only to shut up morons who give this excuse as to why PHP is insecure.
“PHP doesn’t have the concept of a prepared statement.”
This statement is false, but the general gist is that you have to code defensively in PHP to prevent SQL injection, which is true.
Fixing this goes against the central glue-code-only design premise of PHP. For PHP to mandate a solution to this, is for the developers to actually flush their humility down the toilet and say, “I know better than you. Look upon my framework, ye Mighty, and despair.”3 This isn’t going to happen, it’s there in the language, it’s even abstracted for you, program it yourself or find a library that will do it for you.
And while we are on the subject of injection, how many languages have a kernel hook like treat_data? (Sure, it’s undocumented. But like Ragu spaghetti sauce, “it’s in there”.)
“PHP security cures (magic quotes, safe_mode, stripslashes) are sometimes worse than the disease.”
Okay, nobody in the Slashdot discussion said it so eloquently, but we have to forgive them since they just spent the last year writing Enterprise Web Development in J2EE and the sales are dismal.
This is just a security/flexibility tradeoff true for all languages. Since PHP focuses on flexibility, the only solution here is education. I’ll be the first to admit that the whole thing is confusing and one I need to get lawyer’d up on. For instance, my solution to safe_mode is simply to avoid using PHP in a hosted environment.
Education is the way the PHP Security Consortium is trying to solve the problem.
But that is a future article…