'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

[ajrs]

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

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

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