The state of PHP security (LWN article)

Posted on Thu 28 December 2006 in PHP

One of my favourite online publications, the Linux Weekly News, recently published an article called The state of PHP security. Given Stefan's departure, the great taint debate, the addition of ext/filter in 5.2.0 and all of the associated security changes in both the 5.2.x and the 6 branches, I settled down to enjoy a nice pre-Christmas read. I was hoping for some provocative thoughts about the direction that PHP has been taking for the last six months or so in the arena of security.

Unfortunately, I was greatly disappointed. Beyond using Stefan's departure as a kicking-off point for the article, the author didn't even mention any of these issues. Instead, he simply rehashed the history of PHP design missteps (magic_quotes, register_globals, allowing URLs in include) and noted that many PHP tutorials rely on dangerous practices.

What bothered me the most, however, was the author's decision to paraphrase a quote Rasmus gave in an interview from 2002 without explicitly noting that the quote was from 2002. The sentence in the article, talking about register_globals, is:

It is an extremely dubious feature, but one that PHP creator, Rasmus Lerdorf, seems to think should have been left on by default.

Would it have been too much for the author to have actually asked Rasmus if he might have changed his mind in the past five years? Or perhaps the author could have done a little more research and dug up the PHP 6 planning meeting minutes that state that register_globals and magic_quotes were going to be removed entirely from the language. Instead, the author concludes with the following statement:

Security seems to fall somewhere below simplicity in the minds of the PHP language developers; that makes it more difficult to have secure PHP applications. Security is a hard problem and any attempt to 'dumb down' a language is likely to run into security issues. Encouraging amateur programmers to write web applications is unlikely to produce secure code in any language, but by providing tutorials and examples that have glaring security issues and by not concentrating on teaching secure coding, PHP makes it that much worse. A great deal of useful code has been written on the PHP platform; it would be nice to find a way to keep that code coming while simultaneously making it more secure.

The first sentence in that statement is the most damning of PHP developers, but it entirely ignores the evidence exhibited in the changes we've seen in PHP 5.2.0 and that are in the works for PHP 6. The third sentence, oddly enough, attributes the existence of "tutorials and examples that have glaring security issues" to PHP itself, as though the language itself or the core developers of the language have the ability to prevent insecure tutorials from being published.

So I launched into the fray and attempted to right those injustices, perhaps a bit too passionately -- but so be it. I've been pretty quiet in the PHP world for the past while, outside of my little PEAR projects, but I still care about the language.

If I can glean anything from this article, it suggests that it might be a good idea to revamp the landing page and documentation a bit to try to highlight tutorials that teach developers how to write secure PHP applications. Right now the landing page is largely a bulletin board for events. It might benefit, say, from a prominent and permanent link to the PHP Security Consortium (if that project is actually still alive--the last posted article dates back to March 2005). We may also want to improve the visibility of the security chapter of the manual (although briefly revisiting the section on SQL injection suggests that we need to revise it to encourage the use of PDO and placeholders).