'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

[Anonymous Coward]

> 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

Well, sure. Why do you think there are two sets of regex functions in the first place?

PHP is a mess exactly for this reason. Features are implemented several different ways, made to conform to unhelpful C-like syntax, and crammed in wherever they will fit. The whole language is broken, and while security problems are never solely the fault of the programming language, PHP surely doesn't help security nearly as much as I'd expect from a modern Web language.

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

[jgagnon]

I've never programmed in PHP but I do love Python. Python 3 broke a lot of compatibility with earlier versions for the sake of becoming more consistent and a more solid foundation on which to build future versions.

Is PHP headed in that direction as well?

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]

> 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?

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.

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

[jd]

When configuration files get horribly long and complex, it is usually true that they are configuring multiple distinct sub-components. In which case, those sub-components might be best pulled out of the main configuration file and placed in distinct configuration files. Further, sub-components should be responsible for loading their configuration on use. No sense loading, parsing and storing state information that won't be used in a specific PHP application - that just adds to the start-up time without adding any benefits.

My personal opinion of deprecated functions is that if the new function is THAT much better, the maintainers can provide a wrapper that provides the old API but uses the new functions. This can be done as an extra module written in PHP itself, so that those not using the old API don't suffer from overheads and the actual maintained codebase doesn't have extra arcs that need to be tested. The module can then be released as an unmaintained object. Users who wish to keep using the old API permanently can then maintain the wrapper themselves. Those who wish to migrate will have the time to do so, as the old API will only fail when there is an incompatibility between the new API as used and the new API as implemented.

Re:One of the biggest problems is configurability

[Anonymous Coward]

My main beefs with PHP are
1- they aren't consistent with the naming convention of functions/procedures
2- they aren't consistent with the order in which parameters are passed in to functions/procedures

I often have to resort to flat out guessing by trial and error, or refer back to php.net

Re:One of the biggest problems is configurability

[Anonymous Coward]

Name one as large and as mature as PHP with such hideous problems.

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

[ceeam]

> they aren't consistent

Nobody ever is! You know why? Because many functions are direct copies from the C stdlib, for example. Or from W3 DOM or other inter-language API standards. And different standards - gulp - are *inconsistent*!

Yes, it's as simple as that.

(And "native" PHP functions are more or less ok)

Re:One of the biggest problems is configurability

[ceeam]

Python. WinAPI. Enough?

Re:One of the biggest problems is configurability

[Anonymous Coward]

the same problems, maybe, but on a much smaller scale. PHP is the Tucker Max of languages.

Re:One of the biggest problems is configurability

[ceeam]

> on a much smaller scale

Since we don't probably have any formal metric for that, I don't see how we can settle this argument.

By subjective feelings, I disagree.

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

[tepples]

Nobody ever is! You know why? Because many functions are direct copies from the C stdlib, for example.

At least Python tends to rename some functions when bringing them in from C: fopen() becomes open(), etc. PHP prior to 6 didn't even have a consistent way to declare namespaces.

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

[mikael_j]

But Python had a bit of consistency in 2.x that PHP has always lacked. And once you get used to how stuff works in python you can just sort of guess at how various parts of the standard library work unlike PHP where it's seemingly random.

That said, I do hold a bit of a grudge toward PHP since I have some code that I wrote in PHP ages ago and took great care to make sure it was nearly bug-free and now I can't be bothered rewriting it in a more sane language (this is OO PHP4 code with some PHP5 thrown in for kicks, at least all the old PHP3 stuff is gone and I no longer have any mod_perl crap to worry about).

Re:One of the biggest problems is configurability

[Low Ranked Craig]

Personally I keep most of my validation and formatting functions in a single class, and about a year ago I spent 4 or 5 hours and replaced all the ereg with preg. It wasn't that big of a deal and the fact that ereg is going away as been, apparently, known for a long time. I've known about it for over a year personally. Besides preg is perl / mod_rewrite compatible so the expressions are more universal. I don't see the problem here - it's not like all web hosts are going to force upgrading to PHP 6 anytime soon. Hell, most hosts still make PHP 4 available...

Re:One of the biggest problems is configurability

[mikael_j]

Of course, the namespace operator in PHP is "\" which seems to be hated by just about everyone.

Re:One of the biggest problems is configurability

[maxume]

A lot of people get all crotchety because python breaks ABI compatibility with minor versions, so they may not realize that incompatible changes to the language are avoided.

Re:One of the biggest problems is configurability

[jgagnon]

I wasn't complaining about the changes to Python, only commenting on them. :p

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

[Anonymous Coward]

So you're saying that you could get a PHD of PHP?

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

[Bill, Shooter of Bul]

Yeah, you really do have to keep up with a language these days to keep an eye out for the future. I wonder how you managed the transition through the other PHP versions. I mean, you aren't using register_globals or magic_quotes are you? Languages evolve. Programmers must evolve with them. If you don't then you'll get left behind.

Re:One of the biggest problems is configurability

[maxume]

I didn't read your comment as a complaint, I was just pointing out that while the language itself is quite stable, third party libraries, especially C libraries, may still be unavailable, which if you don't agree with the ABI breakage may be quite frustrating (I'm still using python 2.5, partly because of library availability, but I don't find it irritating).

Re:One of the biggest problems is configurability

[D'Sphitz]

error_reporting(E_ALL ^ E_DEPRECATED); // lameness filter too many caps wtf djalfkjasdkl fksjdklf jsakdlj fkldj lfkjsadlk fjlkasdjf lkasjflkjdasklf jlakdj fklsdajkl

Re:One of the biggest problems is configurability

[i_ate_god]

Name one as large and as mature as PHP with such hideous problems.

Java Standard Library? It's a convoluted horrendous mess that requires five times as much code compared to Python or Ruby or even PHP to accomplish.

PHP's messy "standard library" is nothing compared to Java's convoluted "standard library"

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

[Anonymous Coward]

jsakdlj

Hey that's my password. What are you doing with it?

Re:One of the biggest problems is configurability

[Stercus Fit]

It's worse than just the configuration file. In the middle of the 5.2.x development, they changed which value types automatically passed by reference -- in a security patch! 5.2.1 you can modify your arrays in place, 5.2.3 your code is broken. If you want to change the semantics of function calling, you should give the new version a new name; it's a new language. At the very least, you'd better give me a new major version or I'll stop using your platform. I've stopped using the platform.

(I know it was 5.x, it might have been 5.3-ish when all this happened. This rant is from memory. Consider this a pre-emptive [citation needed]. There's no way we were the only ones bitten by change.)

Re:One of the biggest problems is configurability

[the_B0fh]

Some people shouldn't be given modpoints. What kind of moron marks such an obvious joke flamebait?!

Re:One of the biggest problems is configurability

[Anonymous Coward]

So wait, you need an example that is *exactly* like PHP, otherwise you will shoot it down with a worthless one liner?

Well, here's one: PHP

Re:One of the biggest problems is configurability

[tsm_sf]

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.

Perl hard. Make puzzler hurt. Mongo work in java now.

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

[Anonymous Coward]

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

When PHP is the only programming language you've ever used, of course you'll consider it "powerful", "stable", and productive.

Thankfully, the rest of us have used languages like Python, Ruby, Perl, Haskell, Erlang, Common Lisp and Smalltalk, and we know how horrible PHP truly is.

Re:One of the biggest problems is configurability

[Anonymous Coward]

I've ditched php in favor of html + ajax + perl.

Re:One of the biggest problems is configurability

[Anonymous Coward]

It's a convoluted horrendous mess that requires five times as much code

But are search functions always (needle,haystack), or are half of them haystack first?

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

[Hurricane78]

The biggest problem is it being PHP.
Sorry, but as the wise Sioux used to say:
When you discover that you are riding a dead horse, you should dismount. ;)

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

[i_ate_god]

It's a convoluted horrendous mess that requires five times as much code

But are search functions always (needle,haystack), or are half of them haystack first?

This is a huge annoyance for sure. Having coded in all the above mentioned languages, I can definitely say that when I look at explode, stristr, str_replace, etc in PHP, their lack of consistency bugs the hell out of me, but it's easy to work around.

http://www.php.net/ and now I know. Do that a few times and I'll remember.

Re:One of the biggest problems is configurability

[Anonymous Coward]

What you say is absolutely true. When I need value hosting, I go out of my way to find hosts who offer plans that don't include PHP by default. That way I know they're a responsible host, and don't voluntarily compromise their servers by installing software that's knowingly insecure and full of bugs and security holes.

Re:One of the biggest problems is configurability

[nidarus]

Very easy to get from nothing to a fully-functional site. Take a static HTML file, add a couple of tags, move this file into your web root directory, and you're done.

That, and great PHP projects like Drupal (although I don't know if your average Drupal project qualifies as a "web application").

Re:One of the biggest problems is configurability

[Anonymous Coward]

Yeah, you really do have to keep up with a language these days to keep an eye out for the future. I wonder how you managed the transition through the other PHP versions. I mean, you aren't using register_globals or magic_quotes are you? Languages evolve. Programmers must evolve with them. If you don't then you'll get left behind.

register_globals and magic_quotes are such obviously, spectacularly stupid ideas that anyone who's even slightly competent won't have been using them in the first place. That's not true of the ereg functions.

Re:One of the biggest problems is configurability

[Luke has no name]

I learned enough Perl to write file grabbing and parsing scripts within a week of work. This is simple stuff, and it was just as much about learning Regex as it was Perl. Point is, Perl is just another language, thought it is not syntactically beautiful, so to speak.

Ruby and Python both have a strong mainline; there are not several /competing/ implementations as you seem to be concerned about with Ruby. Also, Python is awesome, and lots of people use it. That's why it's made fun of here :)

Quirkz, I get your point. You know what you know it and works. PHP isn't broken, I just don't think it's the best tool anymore. Maybe in the 1995-2005 era, but I think it's prime is past.

To Mr. Shiny And New above, I agree, PHP is everywhere. And that argument is one of the few I appreciate, and it saddens me. It saddens me because that's a circular problem: Something is only cheap and easy because it's used a lot, and it's only used a lot because it's cheap and easy. Python/Ruby are better than PHP IMO.

Re:One of the biggest problems is configurability

[ceeam]

Note to you: you have just used Perl in a positive context in a thread about programming languages consistency.

Re:One of the biggest problems is configurability

[Firehed]

PHP was designed from the ground up to be a templating language for building dynamic websites, and is one of very few languages that can make that claim. Plenty of frameworks have been built to make other languages web-friendly, and they're nearly required to do anything in a cost/time-effective manner. Of course, PHP frameworks (can) speed up development as well, but you can make do without one just fine as well.

Admittedly I may be biased as I develop in PHP all day and literally work five feet away from Rasmus Lerdorf, but I've had that opinion long before that was the case. But except for a single occasion*, I've never found that the language was simply incapable of doing what I needed to do, and what I do requires me to interact with at least half a dozen external services each in a different way (and only one is even using a standard format/protocol). Nearly 100% of the time, any difficulties arise in actually understanding the problem in a meaningful way rather than trying to figure out how to write the code to do the tricky operation, but I guess that's a hazard of having used PHP for the last eight years or so.

That said, the inconsistencies in the syntax drive me insane.

Don't get me wrong - I'm certainly not claiming that it's right for every project, every job, or every developer. It's not. But the amount of time I spend thinking "damn, there has to be a better way to do this" is almost never related to the language itself, and I have to do a lot of weird things in my code (yay, banks).

* and what I had to do violates all good ideas and best practices anyways; unfortunately, the external server is completely out of my control so I can't do something better. The substitute shell script is nearly as much of a hack.

Re:One of the biggest problems is configurability

[Anonymous Coward]

Saying something isn't as bad as the Windows API is the equivalent saying, "At least we're not as bad as China." Maybe technically true, but you're not exactly setting up a good standard for yourself.

Re:One of the biggest problems is configurability

[Anonymous Coward]

anyone who's even slightly competent won't have been using them in the first place. That's not true of the ereg functions.

There is two set of regex function, one of which is faster AND more powerful (preg). Anyone who's even slightly competent would have used it, as there was no reason to go with ereg in the first place. It's not "two good choice and one got better", it has pretty much always been that way.

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

[B3ryllium]

I do agree that many of the function names are, quite frankly, *wacky* ... but the online manual more than makes up for it. I just toss it in my firefox search bar, and I can generally find any function definition (and, in some cases, arcane function names) nearly as fast as I can type it.

I've found it very difficult to find similarly useful resources in other languages (javascript in particular, if you can count it as a language ;-)).

I'm not sure exactly what about it makes it so easy to use for regular reference - but I do know that it is about a billion times better than most docbook-generated documentation I've ever seen. Usually docbook/javadoc makes me want to stab my eyes out with a rusty grapefruit spoon.

Re:One of the biggest problems is configurability

[nxtw]

PHP's messy "standard library" is nothing compared to Java's convoluted "standard library"

Java has namespaces and the standard library uses them. Obvious troll is obvious.

Re:One of the biggest problems is configurability

[merreborn]

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.

When has using a book that's more than 1 major revision behind ever been a good idea? A MySQL 3 book proved pretty worthless when MySQL 4 came out. And MySQL 5 adds all kinds of stuff that MySQL 4 books don't cover.

I just threw out my java books from college because they covered java 1.2.

That's just how it is with programming books. Major language releases make them obsolete.

Re:One of the biggest problems is configurability

[cifar24]

I can related to that. Most people code in PHP because they learn it in 1 day and then they are hooked to it. The power of PHP is its simplicity. We do web stuff with PHP because we tried JAVA and it was TOO costly. To us, any improvement will help as long as it is well documented and documentation has high google page-ranking.

Re:One of the biggest problems is configurability

[KamuZ]

I am a PHP Developer and you are right, when I was checking Rails it was really awesome.

Then I discovered http://www.symfony-project.org/ and it was amazing, give it a try, you will also see how much low level work is eliminated entirely. Their documentation and tutorial is awesome too.

I used to work with Zend Framework but now it looks complex and slow compared to Symfony. Of course as most programming discussions, it is a matter of preference. Pretty sure someone is going to come here and say Zend Framework is the best and symfony is crap :)

Re:One of the biggest problems is configurability

[Bill, Shooter of Bul]

I'm with the other commenter's, ereg is just as bad as magic_quotes, IMHO. Its like you went to a Yugo/Honda dealer saw that the Honda Civic was priced lower than the Yugo, and still bought the Yugo because you thought Yugo wouldn't change its product line as much.

Re:One of the biggest problems is configurability

[usersky]

This is the case with .net developers too. Guys that work developing the IDE and the language are out of sync with reality and they seem to be pround of that.

Re:One of the biggest problems is configurability

[the entropy]

Also, for a language that does have object comparison I find it extremely odd how some functions in the standard library tend to implement comparison. For example, check out the manual for array_intersect. The interesting tidbit:

Note: Two elements are considered equal if and only if (string) $elem1 === (string) $elem2. In words: when the string representation is the same.

I find such hacks in the standard library a turnoff from using PHP. However, as a poster mentions below, ubiquity is its major strength.

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

Re:One of the biggest problems is configurability

[Zarf]

Actually, I'm beginning to think I have some haters. Also... I don't need the karma. I'm capped. So... whatever.

  But, to my fans, I thank you.

Re:One of the biggest problems is configurability

[Zarf]

I can't decide if you should get a +1 funny or +1 insightful ... maybe +1 inciteful? (as in funny and insightful but in an comically trollish way)

Re:One of the biggest problems is configurability

[Anonymous Coward]

It's not obvious that preg is faster if you haven't read it somewhere or benchmarked yourself, and ereg works fine without any brain-numbing stupidities. Also, ereg is more "core", whereas preg feels like a more exotic add-on (yes it's in the main PHP distribution, but so's all kinds of weird crap). If you think ereg is comparable to magic_quotes, you're just deluded.

Re:One of the biggest problems is configurability

[Anonymous Coward]

You think that a POSIX regular expression library is equally stupid as automatically mangling input data? You are just a slimy, sickening apologist for the idiot PHP developers.

Re:One of the biggest problems is configurability

[Anonymous Coward]

"and Python being the frequent butt of jokes here on slashdot hasn't ever made me want to research it to find out more."

This has to be the most piss-poor excuse for not learning something I've ever heard.

Your loss - I'm not gonna waste any time trying to persuade you.

Re:One of the biggest problems is configurability

[Gulthek]

Yikes! So instead of getting to code my models, etc. in ruby or python I have to write XML? Thanks for the pointer, but I don't think I'll be heading down that road.

Re:One of the biggest problems is configurability

[rgviza]

>I call it being happy with what's been working just fine for me over the past decade.
not to mention productive if you've built up a library toolkit of any substance...

One day I may sit down and learn Ruby, but I'm too busy being productive right now...

Re:One of the biggest problems is configurability

[schon]

PHP's strength: ubiquity. PHP is installed everywhere

So what you're saying is that PHP is to programming languages what MS Windows is to operating systems?

Re:One of the biggest problems is configurability

[Bill, Shooter of Bul]

ereg sucks. Preg sucks less. Choosing the one with worse performance and less features, and never examining your decision is not smart. I'm in no way defending the idiot PHP developers, rather I'm blaming Idiot PHP Developers that made a horrible choice because of idiotic decisions the PHP developers made. IN any case as I've said before and will continue to say: languages evolve. developers that don't will become roadkill. You can't complain when a shitty piece of a language is removed, especially when there has almost always been a better choice available. Stop eating dirt, have you heard about chicken? It tastes better and has less rocks in in it.

Re:One of the biggest problems is configurability

[Anonymous Coward]

Google App Engine!

Re:One of the biggest problems is configurability

[KamuZ]

what are you talking about?
You still write your models and can override anything you want really easy.
But it seems you have something against PHP so no need to keep discussing this.

Again, this is just a matter of preference! :)

Doomed

[ISoldat53]

Once a company starts using phrases like "setting expectations" their end is near.

Re:Doomed

[Anonymous Coward]

Yeah... but does Netcraft confirm it?

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.

Re:Setting expectations

[Saeed al-Sahaf]

So, in your biased opinion, it is impossible to write insecure code in, say, perl? C? These languages are perfectly safe for all?

Setting your bias aside, clearly the vast majority of insecure code in any language is not the language, but the way it was used.

The issue with PHP and insecure code comes from its low bar to entry.

Re:Setting expectations

[Vekseid]

When was Facebook's database exposed?

Most security vulnerabilities in major php offerings these days are not php's direct fault, except perhaps as a function of the language's accessibility. If someone creates a script to allow uploading files, and sticks it on a server with both mod_php and mod_perl, and the script doesn't check non-php extensions, how is it php's fault when the server promptly gets owned?

The server owner has a responsibility not to allow one user to threaten others (by running php over FastCGI rather than mod_php), and the script author has a responsibility as a programmer to make a secure application. PHP is not where it was in the 4.x days.

Re:Setting expectations

[Saeed al-Sahaf]

The Parent is not "insightful", it is ignorant and biased. Insecure PHP is a function of the low bar to entry that allows noobs to produce code that does stupid things. The same (and worse) are possible with many languages...

Re:Setting expectations

[Magic5Ball]

When recently helping a colleague with a CMS migration of a few million rows, I had to stop tracking the number of times and ways in which using string functions on not particularly interesting user-submitted data would cause PHP to segfault. It made no difference whether we ran the migration scripts from the command line or an Apache instance, nor whether the host was OS X, Windows, or the various Linux distros we had on hand. And then we got into the image parsing functions, which choke on files saved with particular non-spectacular options in Photoshop (and others) when the underlying GD libraries handle with no issue. Thankfully, we were only using PHP to get the data into the new system, and not as the foundation of the new system itself.

Re:Setting expectations

[the_B0fh]

What kind of moron are you? When did OP say anything about the impossibility of writing insecure code in other languages? What he said was that if the expectation is that most PHP code is insecure, then you will have met the expectation.

Which part of that is wrong?

Stop defending insecure code. You make the assertion yourself with your statement of low bar to entry.

Re:Setting expectations

[Magic5Ball]

With respect to the image handling, the failures on the part of PHP fell outside of the exception handling system presented to the user, and outside its internal facilities. Its attempts to parse some images walled the machines to the extent that local and remote ttys became unresponsive.

A well implemented system should include enough safeguards to prevent the system from failing so spectacularly on easily anticipated use cases, regardless of the inputs that code monkeys, such as allegedly myself, can mash up and throw at it.

In this case, PHP has compromised itself by adding some unsafe logic before or after passing valid data to a known working library. That fault would present itself as much to bad code monkeys and esteemed PHP professionals such as yourself.

Speaking of which, could you please direct me to the PHP professionals code of conduct or the like? I'd imagine that it's the same boilerplate that most others use, but I've not been able to locate one through my simple code monkey Google ful.

Re:Setting expectations

[hardburn]

The language may not guarantee secure code, but it can make writing secure code easy.

For instance, using placeholders in SQL makes code virtually immune to SQL injection attacks. If your database does not support placeholders, then the library can simulate it by quoting bad characters when data is passed in.

In Perl, any tutorial on database usage that anybody will point you to will most definitely show you how to use placeholders. The main one is over 10 years old, and it's very first Perl code example uses placeholders, as do all its other examples that run a query against a variable. It was the correct way to do things back then, and still is. DBI makes it very easy to do it right because there are no additional methods to call to make use of placeholders, and the Perl community is good about showing new programmers how to use them.

If you use PHP with PosgreSQL, then you have the pg_query_params() for the job. Why can't pg_query() do it? For that matter, why can't the equivalent function translate placeholders for braindamaged databases that don't use them? Making the programmers handle this with an escape function is inconvenient. Smarter programmers will have their time wasted on writing frivolous string escaping code, and more noobtacular programmers won't even know what it is or why they should be doing it.

It's entirely possible to write it correctly in PHP, but languages don't differer in what they make possible; they differ in what they make easy. Writing secure code should be much easier than it is.

Re:Setting expectations

[TheSunborn]

And escaping data is not even enough. Look at this simple php code, and find the security bug (It is for mysql, but I guess the pg_query have the same problem). /* Asume an open connection to mysql exists
This function allows any user who can submit to query any field in the database.
  */
function unsafe() {
    $id=mysql_real_escape_string($_REQUEST['userId']);
    $query="select name from user where id=$id";
    $result=mysql_query($query);
      while($mysql=mysql_fetch_row($result))
          print_r($row);
}

Re:Setting expectations

[TheSunborn]

The line
            while($mysql=mysql_fetch_row($result))
should be
            while($row=mysql_fetch_row($result))

Dam why don't mysql have an edit/append feature.

Re:Setting expectations

[rgviza]

or you need to learn to write secure code.

Re:Setting expectations

[rgviza]

This has more issues than just security.

#1 you should never require that a function use GPCS data directly. That makes the function useless for any script that's not used for input via http input vars. userId should be fed via function argument in case you need to find the user's name in other situations and would like to re-use the code
#2 you should use prepared statements whenever user input is sent as part of a query to the database. No matter how well you think you are escaping it, there's usually a way around it. Prepared statements precompile the query and delineate the data explicitly from the SQL code, which makes SQL injection impossible.
#3 mysqli functions are a far better option than the standard mysql functions for many reasons, I strongly suggest you learn it, build a mysqli data access library and use it.
#4 mysql_real_escape_string doesn't protect against sql injection, it only escapes non-printable characters
#5 Never use _REQUEST unless you are expecting input from all of GPC on that particular array element, and you handle all of the vectors. If you are only expecting data from _POST, use _POST. /shrug

That's just the first 2 lines.

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.

Re:Doing something about it.

[Hurricane78]

Yeah. Like walking trough Nazi Berlin 1944, seeing 60 cases of deadly friendly fire by the Nazis, and declaring their action a good thing. ;)

Considering my 7-year experience with PHP, I’d say that the easy to find bugs are only artifacts of the horrible horrible architecture underneath.

A interpreter/compiler that allows you to put plain text right between your lines of code like this

<? echo "EVIL";
blablabla
echo "PHP" ?>

and not throw an error because it considers any string without quotes to be a string anyway (or a constant, or...), which can be in an expression, which itself can be a statement with its result thrown away,
deserves to be compared to something as completely insane as the above example. ;)

Also, I only have to say “implicit casting guesswork”, to raise the hairs of pretty much every real programmer out there.

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.

Re:Magic quotes or magic drugs?

[Gulthek]

Ugh, I blocked that one from memory. You know you're in for a fun time when the function has "magic" in its name.

The only language where reinventing the wheel...

[Vekseid]

...can be a good idea as a standard practice.

Bugs in the bloated function list can last for years. Interfacing with external applications can often be incomplete - see the memcache versus memcached extensions. The best solution in one version may not be in the next, and may not even be available shortly after (see all the changes they are making to version 6).

And yet, php is good where it dominates - pulling data from MySQL and shoving it through FastCGI. If someone ends up forking php 5.3/5.4 to flesh it out as a language, I would seriously consider looking at it.

Untrusted developers

[billcopc]

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

People must rely on a size 13 boot to the head for securing against untrusted developers.

I mean really, if you don't trust your developer, fire the incompetent lying sack of shit. I don't consider myself a super coder (anymore), but it's not exactly rocket science to secure the average PHP script. Sanitize the inputs, escape any SQL parameters (or use prepared statements), and if your app needs to do stuff like "exec('sudo rm -rf /')", you just might want to rethink what it is you're trying to do for your lusers.

The reason PHP takes so much flak is because it's a very popular, rather easy, and embarrassingly sloppy hodge-podge of diverse functionality. By that virtue, it attracts a larger-than-usual share of troublesome coders and users. Nobody's ever really heard of vulnerabilities in, say, A+, because there's only about 3 people who use that language.

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.

Re:Untrusted developers

[the_B0fh]

I am not sure which language I would prefer more, brainfuck, or APL.

Re:Untrusted developers

[adamofgreyskull]

ACK that. Slightly OT, but humorous. At a php conference in London a couple of years ago, in a talk by Stefan Esser on PHP Binary Analysis a guy, possibly the guy referred to in this post, claimed that he had a commit trigger that detected calls to exec() and e-mailed him, so he could summarily exec('sudo rm -rf /') the committer. Everyone laughed, but I have the strangest feeling he wasn't joking...

Re:Untrusted developers

[AliasMarlowe]

I am not sure which language I would prefer more, brainfuck, or APL.

APL, no contest. When it's done right, it's a non-stop brainfuck.

Re:Untrusted developers

[Anonymous Coward]

Actually the true story is that someone in the audience told him that he disallows eval() in his company and Stefan replied that he could use the techniques to introduce an autocommit hook that detects eval() and sends an email to the commiter telling him that he is fired.

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:Why stop at blaming the OS for insecurity?

[loufoque]

The proper way to have security is to run a PHP process per user, each running with the uid of the user in question.

This has performance concerns, so some people designed a hack (which was eventually deprecated at some point) so that you can have security even when running PHP as an apache module, which means all scripts get run within the same process with the web server's uid. With that hack, PHP artificially does security checking between the owner of the php file and what a process with that uid would be allowed to do. Except to the OS, it is not that uid, which means that approach is completely broken and has a lot of issues: when you create a new file, its owner is the web server since that is the uid of the process which created the file, but you're not allowed to write to it because that doesn't match the owner of the script. Which means scripts need to do chmod and give write access to those files to everyone, meaning security becomes moot.

There is no other way to have proper security without running one PHP process per user with the appropriate rights, just live with it. It's not shifting the blame, it's just than PHP uses the operating system, and for the operating system to function properly you need to follow its rules.

Why are you assuming people will up and drop php5?

[Vekseid]

php 6.0 isn't even finished yet. It took years for php5 to get adopted - which isn't even available on some crappy hosts - and the inertia holding php5 is going to be that much stronger, if only because it's not in the atrocious state it was in with version 4. People aren't going to pick up version 6 on a whim, exactly for reasons like this.

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.

Proper Coding Practices

[epp_b]

If you "can protect against [the bugs] with proper coding practices", are they really "bugs"? I would say not.

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

Re:Proper Coding Practices

[Just Some Guy]

If you "can protect against [the bugs] with proper coding practices", are they really "bugs"? I would say not.

Description: all built-in functions are insecure and will poison your cat and sell your organs.
Workaround: re-implement all native functionality yourself.

QED.

Re:Proper Coding Practices

[mandelbr0t]

Yes, they are. Because the main issue is that many sites host PHP from untrusted users, and don't have time to go through every script with a fine-toothed comb. Assuming that the people who write PHP scripts are capable of using proper coding practices is kind of like assuming that your teenager always tells the truth. In rare cases, it might be true, but you're an idiot if you believe it.

Security flaws and good coding practices?

[gsgriffin]

Everyone posts that simply good coding practices will solve your problems. I didn't read through all of the security flaws they are now reporting, but good coding doesn't overcome flaws in the language. If these flaws allow for security problems, it is of great concern! When parts of a language don't always function they way you expect, how are you supposed to code. I really don't want to have to code exceptions, triggers, catches and the like for every part of the language I use. That's silly. Don't tell me proper coding solves all security flaws when you don't even know where the bugs are.

P.S.:

[Hurricane78]

LOL, yes, the above PHP example will complain about the semicolon missing behind the "PHP". *sigh*

Anyway... I thank PHP... for giving me the motivation to finally learn Haskell. :)

Redhat 5 a problem which php 5.1 only?

[felix9x]

I find it very confusing that Redhat server version 5 only provides 5.1.x php as a standard installation.

This is not even an still a supported branch of php by the php community so I assume none of these fixes that will be coming out in the next php 5.2.x or 5.3.x version may make it into RedHat 5 server. Considering that none of these holes are considered critical is more reason for RedHat to not bother with backporting.

Anyone find it a problem that Redhat installs in corporate environments do not provide a php version that is under active development?

There might be some method to the madness.

[Anonymous Coward]

I ran into this one today.

array_search(needle, haystack) - returns first occurrence of needle. If you need all the occurrences use array_keys the the optional array_search parameter. That is...

array_keys(haystack, optional needle)

Ugh.....

But wait, I guess that makes sense because the needle is optional for array_keys but you always pass the haystack.

It's a nasty mess but it work fairly well. Just keep the docs handy.

Re:There might be some method to the madness.

[Dylan16807]

I think haystack first makes more sense as haystack is the subject you're working on, but if the needle is going to be first just make the first parameter optional, don't screw up the pattern.