PHP Security
December 14th, 2006 | by admin | suraski.netI’ve just been misquoted on Slashdot, as if I said there are no security problems in PHP itself, and that I instead point my finger only at inexperienced developers.
If you read the original article on Heise Security, you’ll see that I have not said anything of the sort. While I hope Slashdot fixes this story, I thought I’d make my stand on this clearer. I believe this is the belief of most others on the security team, but I’m only speaking on behalf of myself and do not represent them.
1. Fact is most security problems that are published that have to do with PHP, have to do with problems at the user level, i.e., bugs in the application written in PHP. There’s no point arguing about this one, it can be proven by simply looking at the number of published advisories that had to do with PHP itself, vs. the number of advisories that had to do with applications written in PHP.
2. There are many reasons for the fact there’s a large number of security problems in PHP Web apps. First and foremost, it’s the fact PHP is by far the most popular platform for building Web apps, and I believe it’s also the language with the largest number of opensource ready-to-use Web apps out there. If PHP accounts for, say, 50% of the opensource Web apps deployed on the net (a reasonably conservative assumption), half of the problems in Web apps would have been in PHP apps just from a statistical point of view. Also remember that it’s much easier to create a Web app that’s exploitable than a desktop/backend app that’s exploitable, if only for the fact that Web apps are (almost) by definition remotely accessible, turning even minor glitches to problems with real security implications.
3. Another reason for certain classes of security problems in PHP can be blamed on the language itself. Two such examples are register_globals (handled in PHP 4.2 several years ago) and the default support for URL include()’s (fixed as of PHP 5.2 a couple of months ago). These are not strictly language bugs, but instead, features (or misfeatures) that make it all too easy for novice developers (and sometimes even advanced ones not paying attention) to fall into security pitfalls. While not a language problem from a strict “computer science” point of view, I think everyone on the PHP dev team perceives those as problems that need to be addressed, and contrary to the misquote on slashdot, nobody, or at least not me, is pointing the finger at inexperienced developers. It’s their fault, but our responsibility, if you will.
Yes, we could have handled the remote URL inclusion faster, but saying we don’t care about such issues is just false.
4. And now for the scoop. YES, there ARE security problems in PHP. PHP itself, as in the code in C that implements the language. If you didn’t get a stroke from reading this scoop and you’re still with me, I’d like to point out that I can hardly think of any other project in such a scope and of a similar nature that doesn’t have security problems in it, at the same rate (give or take) as PHP. I’ve never said anything to the contrary in the past, and I don’t expect to ever say something else in the future. I do mention, whenever I’m asked about PHP’s security, that most of the problems happen at the user level - but it doesn’t mean that PHP doesn’t have security bugs in it as well.
5. I believe we’ve had an excellent track record at fixing remotely exploitable problems and coming out with fixes immediately, and there haven’t been that many of them either.
Stefan’s talk about being considered “persona non grata” because he ‘had the guts to stand against us’ is completely false, too. I’m not going to get into the details of what brought Stefan to call it quits, but suffice to say that it had nothing to do with the published reason, and more to the interaction between Stefan and other members of the security team, and the dev team in general.
Finally, I’d like to take the opportunity, again, and ask Stefan to come to come back to security@ team, and work with the project and not against it. As any project that has hundreds of people contributing to it, you never find yourself in agreement with everyone at any given time; It doesn’t mean that those who don’t think exactly like you are your ‘enemies’, and it certainly doesn’t mean you should quit and turn to the ‘other side’.
Zeev
Related Posts
Tags: Security
