'Month of PHP Security' Finds 60 Bugs

darthcamaro writes "More than 60 bugs were reported in PHP over the last 30 days by the Month of PHP Security project. Most of the flaws, however, are ones that developers themselves can protect against with proper coding practices, according to Andi Gutmans, CEO of commercial PHP vendor Zend. He argues that PHP security is a matter of setting expectations. In his view, PHP — like all development languages — is only as secure as the code developers write with it. 'People should not expect PHP to be able to enforce security boundaries on a developer [who] has permissions to run custom PHP code,' Gutmans said. 'It's an inherently flawed scenario — and it's the wrong layer to protect in. People must rely on properly configured OS-level permissions for securing against untrusted developers.' Gutmans also praised the MOPS effort for elevating the profile of PHP security throughout the community, and for responsibly alerting the PHP project first with the bugs they found."

Comments

One of the biggest problems is configurability

[suso]

Sorry this is long, I could probably write a whole dissertation on my thoughts on PHP though.

I've been developing in PHP since version 2 way back in '97 and I've always felt that one of PHP's biggest downfalls is that it has a configuration file. I understand that it has more to do with its origins as an Apache module, but I can't think of many modules or programming languages that are so customizable as PHP is. Over the years this has led to different schools of programmers choosing one setting or another and chastising people who use a different setting.

Another big problem is that the core developers don't seem to get just how large the PHP community is. I found out some months ago that they were deprecating the ereg/POSIX regex set of functions in 5.3 and will be removing them in 6. I bought up on the mailing list that I think this is too quick of a time table for it being removed and that they should have it marked deprecated for at least 1 major version before removing it. Their excuse was that they really wanted to get UTF-8 support in PHP (a commendable goal) and the ereg functions weren't compatible and are also too slow. So now they are pushing the preg functions which are based on PCRE. Ironically all this time I've been avoiding the preg functions because I figured they were the more likely candidates to go away.

And I'm not alone. Many many people out there have been using ereg in lots of code over the past decade and its going to be a huge shock for them when it comes time to switch suddenly. When 50%+ of the dynamic web uses PHP, this is going to cause lots of problems over the next 5-10 years.

Yes yes, I know that there is work on a PEAR module to substitute the functionality of ereg, but my point is that the core developers seem to be in their own world and aren't thinking about the overall affects of their decisions and how far reaching they are.

Re:One of the biggest problems is configurability

[MightyMartian]

The configuration file is a problem, to be sure, but the real problem is their insane library which seems to fit no particular convention. It's goddamned madness and makes coding an incredibly painful experience as you constantly run back and forth to the online manual to get the exact name of the function. Out of that comes the constant deprecating and synonyms. I find PHP a painful, awkward language to code in, but because I do so much work supporting legacy stuff, I'm stuck with it.

Re:One of the biggest problems is configurability

[ajrs]

You young kids and your legacy php applications. Get off my network.

Re:One of the biggest problems is configurability

[ceeam]

Any sufficiently useful in real life set of libraries suffers from the same problems.

Re:One of the biggest problems is configurability

[Gulthek]

"Now" they are pushing preg functions? Everything I've read on PHP for the last five years has been drilling "use preg instead of ereg because ereg is slow and going away". This isn't a sudden switch either, you've already had months to transition and you still have many more months before you need to cut over.

I can live with the settings file, PHP has many more fundamental flaws than disparate configurations. The only real configuration schism I'm aware of was register_globals vs. not register_globals.

Global namespace stuffed full of built-in functions. Inconsistent argument order for built-in functions (needle, haystack || haystack, needle). Inconsistent naming scheme for built-in functions. PHP is a dumb language when it comes to including other code, it doesn't even have a concept of "other" code: an include/require statement just dumps the entire contents of the file being pulled in.

I could go on.

Yes, I code PHP for a living.

Re:One of the biggest problems is configurability

[suso]

> Ironically all this time I've been avoiding the preg functions because I figured they were the more likely candidates to go away.

Sorry this is short, but are you *that* dumb?

I must be.

Anyway, I remember seeing (in official docs) the note that ereg functions will occasionally be dropped like 5 years ago when I first started with PHP. And the fact that PCRE functions are *much, much* more powerful is very obvious.

Well good for you. Like I said, I've been using PHP since '97 and I don't usually have to go back to ereg page of the manual much. I know PCRE is more powerful (I do lots of Perl programming too so maybe I am dumb), but there are lots of functions like that in PHP where someone thought it would be cool to add it in, so it got included, but not all of them last and I wouldn't want to write code based on something that would get deprecated. Since ereg has been around since the beginning, I figured that it would be less likely to get deprecated.

As I brought up on the mailing list months ago when I was trying to make my case, of the books in the top 10 search results for PHP on Amazon, 5 or 6 of them, including the book by Rasmus himself (wrote PHP originally), use the ereg functions in their examples. So you can imagine that there are lots of people out there learning basic search functions out there that will be going away in the next major version. This is not good.

Re:One of the biggest problems is configurability

[0racle]

I wouldn't say that Perl or Python suffer from what PHP suffers from.

Re:One of the biggest problems is configurability

[mcrbids]

I use PHP and I love it as a language. It's powerful, stable, and lets me get lots of work done quickly.

That said, you hit on the two biggest annoyances I have with PHP:

1) Argument order: is it myfunction($haystack, $needle) or myfunction($needle, $haystack)? There's no rhyme or reason that I can consider, mostly just random stuff.

2) Function names: Is it going to be isinteger() or is_integer()? And even within a set of otherwise closely rlated functions, while php has is_integer(), is_set() is actually isset(). Who thought this was a good idea?

Again, I don't want to knock PHP too badly, it's a lean mean workhorse of a language, and its many strengths vastly outweigh its weaknesses. But couldn't they pick a convention and move to it?

Re:One of the biggest problems is configurability

[shutdown -p now]

Stock Python libraries don't suffer from this to the extent PHP ones do.

WinAPI is twice as old.

Re:One of the biggest problems is configurability

[Zarf]

I wouldn't say that Perl or Python suffer from what PHP suffers from.

No. They don't suffer from it they thoroughly enjoy it.

Re:One of the biggest problems is configurability

[ducomputergeek]

Our front end has been PHP for a while because it was popular and we could find developers easily. And when we were in the development, speed and the ability to find programmers was a primary concern. However now we've added all the functionality needed and it's a mature/stable product, but in the last 18 months we've noticed quite a few of these "You shouldn't use thisFunction() because it is deprecated". Every couple months when we upgraded PHP to the latest version it seemed like we'd start seeing new warnings that some function we'd been using for years was being deprecated. The last straw for me was the deprecation of split(). We were spending more time for maintenance than what we wanted to commit to the project at this stage so we ended up porting the frontend to Perl. The backend had been Perl based since 1999/2000 and the last time we had to do any updates to those scripts was adding functionality in 2006.

I know Perl is not sexy these days, but we use it a lot for things that we need done but don't want to spend a lot of time on maintenance. And I catch flack from some of the programmers who always want to use whatever "new hotness" is this year. But I'll take stable and mature any day of the week.

Re:One of the biggest problems is configurability

[Luke has no name]

This, and the lack of a namespace concept (until recently) make me wonder, "Who would begin a greenfield web application in PHP when you have Python/Ruby/(kinda) Perl?" These are all strong languages. Ruby is fascinating, though it's only now coming into its own.

Seriously, tell me, because I don't get it. You say its strengths outweigh its weaknesses. We've pointed out some damned big weaknesses, so what are its unique strengths?

Re:One of the biggest problems is configurability

[Jack9]

The configuration file is a problem, to be sure

Why? Lots of languages use or require configurations for their interpreters/compilers. If the ini was such a big deal, there would be an implementation without one. Unfortunately, there's too many reasons to HAVE one.

Re:One of the biggest problems is configurability

[pjfontillas]

Hopefully someone who does get the joke and has mod points can help fix that. That's how the system is supposed to work... now if it would actually happen...

Re:One of the biggest problems is configurability

[Mr. Shiny And New]

PHP's strength: ubiquity. PHP is installed everywhere, so if you are intending for your application to be deployed on diverse machines with low-cost hosting it is a good bet. I like to code in Java but for my home website it's all PHP because that comes free with my hosting provider, whereas better environments are more complicated to set up or more expensive.

Re:One of the biggest problems is configurability

[Quirkz]

"Who would begin a greenfield web application in PHP when you have Python/Ruby/(kinda) Perl?" These are all strong languages. Ruby is fascinating, though it's only now coming into its own.

Well, I'm one of those people. In college I was trained in Fortran and then C++, and PHP has always seemed pretty friendly and intuitive in comparison with those. At least on the surface other than minor differences in syntax I could transition from one to the other to the next without too much difficulty.

Every time I've looked at Perl, it's been downright indecipherable. I've edited a few existing scripts, tried reading not one but two books on it, and mostly I walked away feeling just as confused as when I started.

As for Ruby and Python, when I started needing to code web applications, I'd never heard of them. They may be coming into their own now, but why should I start over with a new language when I can already do what I want with PHP? I don't know much about either, but at least peripherally I've been confused by some impression that with Ruby there are varying implementations (on Rails versions, versus who knows what else), and Python being the frequent butt of jokes here on slashdot hasn't ever made me want to research it to find out more.

It may be a poor excuse, but that's why I'd start my next project in PHP. You may call it prejudice and ignorance against other languages; I call it being happy with what's been working just fine for me over the past decade.

Re:One of the biggest problems is configurability

[Gulthek]

That's only because you haven't taken a serious look at Django or Rails. Every diehard PHP coder that I've shown something like the Django admin interface, web form creation/management or something like ActiveRecord and fundamentally integrated testing in Rails has been absolutely stunned at how much low-level work has either been obviated or eliminated entirely. Both frameworks really free you to work on the high level fun stuff of a web application.

If you want a quick look at Django and don't mind not "getting" it all, the book "Practical Django Projects" is most excellent.

For Rails you'll probably get the most out of "Rails for PHP Developers".

Have fun!

Re:One of the biggest problems is configurability

[Parker Lewis]

This it's not true on the real world. PHP can be configurated in too differente ways that you cannot guarantee almost anything will work on a different host machine. I code in PHP the most part of the time, and there is almost nothing that can be assumed as "write once, run anywhere".

Setting expectations

[0racle]

As long as you expect PHP and the majority of code written in it to be insecure, you're expectations will be met. We call this setting your expectations appropriately. If you expect security from PHP, well, you need to learn to set your expectations appropriately.

Doing something about it.

[AndGodSed]

At least they are working on finding bugs. The fact that they _found_ bugs shows that they are doing a thorough job.

This is A GOOD THING (TM)

Re:Doing something about it.

[ianpatt]

The PHP developers didn't find these bugs, Stefan Esser did. (see http://php-security.org/)

The fact that one of the bugs still remains from his original /2007/ Month of PHP Bugs shows that the PHP developers are clearly not doing a thorough job.

Magic quotes or magic drugs?

[tepples]

I can live with the settings file, PHP has many more fundamental flaws than disparate configurations. The only real configuration schism I'm aware of was register_globals vs. not register_globals.

That and magic_quotes_gpc on or off. The ill-advised feature was on by default in PHP 4, and though official PHP 5 turned it off, a lot of shared hosting providers turn it back on to remain compatible with legacy PHP 4 code that their hosting clients might still be using.

Why stop at blaming the OS for insecurity?

[prgrmr]

People must rely on properly configured OS-level permissions for securing against untrusted developers.

Why not also blame the web server, the middleware (e.g., Tomcat/Jboss/etc), the database, and the client-side browser as well? While security problems at these layers certainly exist, they don't excuse any problems in PHP--and they certainly don't exonerate any developer for writing insecure code in the first place.

Re:Untrusted developers

[Hatta]

What if that untrusted coder is not an employee, but a customer? If you're hosting websites, and your client wants to write custom PHP, you need to rely on your OS features to ensure that his insecure code can't damage other users.

I would laugh...

[Vekseid]

The fact that one of the bugs still remains from his original /2007/ Month of PHP Bugs shows that the PHP developers are clearly not doing a thorough job.

...but this sort of thing just makes me want to cry. Multiyear bugs exist in multitude. And these are just the ones they admit exists.

Re:Proper Coding Practices

[Dan Ost]

But because the work-around for a bug is common knowledge doesn't make the bug any less of a bug. It does, however, give the devs an excuse for not fixing it, or making it lower priority than bugs that have no work-around.

Re:Proper Coding Practices

[webbiedave]

proper coding practice != workaround