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.
Make sure register_globals is off (which it is by default). You then can’t assign “arbitrary values to variables via parameters embedded in the URL” except for the specific superglobals (e.g. $_REQUEST).
Sorry to interrupt, bit Stephen is right. Since PHP Version 4.x the register_global is per default OFF! Unfortunately several best-selling php-applications require it for “historical” reasons. It is extremly easy (but time consuming) to re-programm these applications.
Please do not justify PHP for a single option but for the programmers. The demanded “redesign” is long since integrated.
Whilst comparing: Even Perl, Java, JSP, ASP can have arbitrary values/parameters. But ASP for example offers functionality to distinguish the way the variable and value was introduced (PHP does, too, btw).
No, PHP does not require a redesign. PHP requires to seal close and break the habbit to be as downward-compatible as possible.
Redesign the programmer; remove bad examples in the web!
It seems that I’m not the only one who thinks that using PHP is not a good idea:
http://maurus.net/resources/programming-languages/php/