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.”
How true.
I better start writing some stuff, before they kick me out of the “all-star PHP line up”.1
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…
Apologies for the offtopic comment, but your RSS 2.0 feed appears to be broken. Thought you might like to know 🙂
> Then they go around blaming the PHP language for their own
> incompetence.
http://www.phpbb.com/phpBB/viewtopic.php?t=248046
I am not sure I understand what you mean. Is it factually wrong what is written in that post?
A couple of years ago i already said that PHP would get the same reputation as Visual Basic because it has a low entry level. I guess time has come 😛
It’s probably the worst piece of paper I ever read about PHP security. With your kind of morron, it’s normal to see where the PHP “expert” community is going. There’s no such looser arguments than those you wrote on this blog. Come on. We, PHP programmers, doesn’t need this kind of material. And I wasted trees by printing this entry… Sick.
Feel free to write me back if you want it.
Thomas Faell
Sweden
P.S: Sitepoint.. don’t ping this article please. It’s ridiculous.
I’m fairly certain the “global namespace” comment in that Slashdot thread was in reference to modules and their functions, not variables.
OT: it seem that both feeds are non valid (feedvalidator.org thinks so) and neither is this page ( Line 112 column 97: there is no attribute “titile”.)
@Sencer: Did I link the wrong thing? If so, I apologize. Ilia explains why the unserialize bug in PHP is a phpBB security hole.
@Thomas Faell: Your response: the ad hominem, the nebulous attacks, the absolutism…
*swoon*
I can only hope to get my forensic skill to the razor sharp level you have. But you see, my wit hasn’t been honed through years of Slashdot commentary. You must forgive me, I am but the apprentice.
@Justin: reread the reference and you are correct. My bad. The guy seems to be confusing security with the orthogonal issue on “why PHP won’t scale.†which had me further confused because of it was jammed between two threads talking about register_globals.
I fail to see how the sometimes convention (underscoring to prevent function collision) represents a security hole in anything but a highly contrived example, but an argument can be made for namespacing as necessary for scaling. I should address that in another article. (How PHP doesn’t need namespacing to scale, why PHP needs namespacing, why it’s harder to do than it seems, and if PHP scales or not).
@verbat, @Lox: WordPress bites. I didn’t even bother to change the default theme. But I thought nobody was reading my blog. It’s hosted off my home DSL so if you pee in the right direction you might take it down. 🙂
Ad: “PHP shoves a mess of shit into the global namespace.â€
In my opinion “global namespace” is a real problem in PHP. It concers function, not variables! Try searching a function if you dont know its name. Additionaly function list looks like a big mess. Modules allows one to control what, where and why. Now, when browsing poor code, it more “find function definition” then “think if its necessary”.
After an IRC chat earlier, Magnus Määttä picked up this entry. Heh.
Thomas Rutner of Sitepoint picked up this entry. He is sensitive to my point that poor security is justified by ease-of-use.
I don’t think it is necessarily meant that it is justified. My article’s point was to say most of the security arguments leveled at the PHP language are fallacious and that the only designed-in security weakness in the language are there because of flexibility, backward-compatibility and ease-of-use (for the developer). It was a language tradeoff. And, since, we have yet to find the “one true programming language,” it is a compromise we make when we choose program PHP.
I certainly would like to see the elimination of safe_mode and magic_quotes, but adoption of PHP might suffer. Perhaps later versions of PHP may eliminate it as current versions deprecate it. I believe that insecure PHP programs can be offset by education, but that was another article, which I never wrote.
Wojtek, I agree that the global namespace is a weakness, but not from a security standpoint. I think it limits the size of PHP applications that can be deployed sanely.
However, PHP is a language designed as glue code. There is nobody holding a gun to anyone’s head and saying that the entire thing has to be coded up from within the PHP runtime. Good policy/convention + OOP within PHP can allow an application to grow to a large size. Web services and extensions (a la Yahoo!), allow it to grow even bigger.
Besides, at one time PHP didn’t have OOP support, now it does. Who is to say that namespaces might not be treated in the same manner.
Chris Shifflet picked up this entry.
International PHP Magazine picked up this entry.
PHP Developer picked up this entry.
Everything Sux disses my article by claiming the problem with PHP Security is a social problem with respect to the PHP community.
I wonder how this argues against my thesis in this article: The problem is not in the language. Actually, the social aspect of PHP community was the thesis for part II of this article (which I never wrote).
>I wonder how this argues against my thesis in this article: The problem is not in the language.
??
Lufamux,
My point that that the problem with PHP Security is not inherent in the PHP language itself does not contradict verb’s “different idea” that the problem with PHP Security is with the community.
I actually agree with that idea and was the topic for a part II I never wrote. 🙁
Hope that helps,
terry
Keep a good job up!
Alasdair links this entry noting some of the Yahoo! filtering hooks I mentioned.
Interesting writeup on the 5th anniversary of register_globals = off.