I’ve updated a package of the NetBSD package source collection today. The package contains a PHP application which surprisingly required a security fix. And I have committed a lot of security updates for PHP based packages to package source recently. And from what I read on the Heise Newsticker it looks like there have been a lot more vulnerabilities in PHP based web applications recently.
The amount of such security holes which are always caused by the same problems (uninitialized variables, cross-site scripting, etc.) make me wonder whether the design of the PHP language is flawed. Yes, there are also a lot of security holes in applications which were writtten in C or C++. But these programming languages are much more versatile and therefore used to solve much more complicated problems.
PHP however is an application language. It was designed to write web applications. And based on great PHP products like WordPress or phpMyAdmin it seems to do that job very well. But it seems that security was not a design goal when the language was created. E.g. being able to assign arbitrary values to variables via parameters embedded in the URL is a really bad idea. Even the ancient cgiparse program which was part of the W3C HTTP daemon distribution was clever enough to prefix all shell variable names to stop a remote client from overwriting important things like the PATH variable.
Perhaps it is time to redesign the PHP language. The new version should not try to be fully backwards compatible. It should instead remove all those features which have caused security problems in the past. That will of course require changing a lot of existing PHP code. But anything else will just result in more problems in the long term.