Some thoughts on WordPress security

Posted at 11:30 on 27 July 2007

I've been thinking a bit more about what to do with my blog. More from a technical perspective than anything else, mind you -- I have been wondering a bit whether WordPress is the best solution to use for it, and if not, what I should be using instead.

WordPress is very popular and very fully featured, but it has a poor reputation when it comes to security. Stefan Esser, of "Month of PHP Bugs" fame, is particularly critical -- a week or so back he gave an interview on BlogSecurity.net about the problems with WordPress, citing architectural problems that make it difficult to write secure code.

I must admit that while there is a lot that WordPress does very well -- it is a very full featured application, supported by a lively community -- I find its codebase pretty tacky. Some of it isn't too bad, but the admin section in particular is a right unholy mess, with HTML, PHP code and SQL statements bundled together haphazardly in a monstrous plate of gone wrong spaghetti bolognese on the loo.

Matt Mullenweg is pretty defensive about WordPress security, however. In a blog entry about a month ago, he made the point that (a) all software has bugs and security vulnerabilities, which is true, and (b) that the WordPress developers do a great job of tracking down and fixing bugs and security holes before releasing a new version, which is also true. However, he did not address the point that the overall architecture of WordPress makes the process of tracking down and eliminating bugs -- and keeping out whole classes of certain bugs in the first place -- unnecessarily difficult.

The fact that Mullenweg has stated his opposition to the long overdue GoPHP5 initiative and the end of life of PHP 4 is also far from reassuring. PHP 4 may still be amazingly popular, but it has some serious shortcomings as a language which make it much more difficult to write robust, secure and easily maintainable code -- shortcomings which were addressed in version 5. It has no support for parametrised queries, for instance, forcing developers to adopt the dangerously insecure practice of concatenating SQL code and user input to construct database queries. In an attempt to protect against SQL injection attacks, PHP offers magic quotes -- an ugly, naive, broken and widely criticised hack that causes more problems than it solves and doesn't always work.

What makes this more serious is that these days, writing WordPress plugins and themes is for many people the introduction to the world of software development, and while it does need to be kept simple so that newbies can learn and participate to some extent, it also needs to show the way in terms of good programming practices and robust code, and when you are using a language that limits your ability to do so, it is not good.

So how could WordPress improve in this respect?

First of all, the WordPress core team needs to take PHP 5.2 seriously and sign up to GoPHP5. The new features of PHP 5 are not merely luxuries; they do make it much easier to adopt good programming practices and write robust, easily maintainable code. It would not make it more secure overnight, but it would make it considerably easier to evolve it towards a better, more secure, more robust and more easily maintainable architecture.

Secondly, it needs as complete a suite of unit tests and integration tests as possible. I know that there are moves afoot to add unit testing to some particularly error-prone parts of the application, but the automated tests need to go beyond this and cover as much of the code as is possible. These would not only increase confidence in the code quality dramatically, they would also make it a lot easier to track down and fix bugs that creep in during development. Automated unit and integration testing seems much less common in PHP open source projects than in their counterparts in .NET or Java, and if WordPress takes a solid lead in this respect, it will be a smart move and bring them kudos among serious developers.

This would, however, necessitate some fairly fundamental architectural changes. It is much more difficult to write meaningful unit tests for an application with a monolithic structure where HTML, PHP and SQL code are all wrapped into one than for an application that adopts a three-tier or Model-View-Controller approach. This does not have to be done all at once, and it does not have to become fully object oriented, but WordPress does need to move towards a more structured approach with a better separation of concerns between database access, network communications (such as e-mail and pings), business logic and the UI.

Finally, the upgrade process needs to be made as simple as possible for the end user. I wrote a while back about how we have moved to a scripted, single step process for one of our major projects, which makes the process of applying changes a doddle. WordPress needs to do something similar. It can be, and should be, as simple as pressing a button on your dashboard. Novice users certainly should not need to bother with making backups, FTPing some parts of the application and not others, and so on -- it is an error-prone process that can be so daunting for inexperienced users that there are still a lot of blogs out there running WordPress 1.5, wide open to attack.