December 20, 2006
This article was contributed by Jake Edge.
PHP security has been much in the news lately, mostly centered around the
resignation
of Stefan Esser from the PHP Security Response Team. His stated reasons
for leaving are rather alarming, and he indicates a pattern of slow
responses to security holes within the language itself. Others, including
Zend co-CTO Zeev Suraski,
disagree
and chalk it up to a personality conflict between Esser and the rest of the
team. A recent
look at the
National Vulnerability Database (NVD)
specifically for PHP related security issues also highlights some of the
problems with PHP. It is time, it seems, to take a look at the state of PHP
security.
PHP is touted as an easy language to use to write web applications,
particularly those that use a database for storage. There are no end of
PHP tutorials available on the web that will help readers to get
a web application up and running in short order. Unfortunately, many of these tutorials
completely ignore security and invite their readers to create
applications that suffer from SQL injection and other security flaws. This
example
(from the top ten results of a Google search for 'php tutorial') explains
how to update a record in a MySQL database using single quotes around
the values that come in from a web form. It also describes how to display
data in ways that allow for cross-site scripting.
As described in another security page
article, the proper way to
handle database queries with
user supplied data is by using placeholders. PHP does provide ways to
do that, using the PEAR database API,
but finding information about it is non-trivial. It certainly is not
promoted by the PHP homepage, which tends
to push the included, easily abused, MySQL interface.
Because PHP strives to be easy to use, its developers have added features
that have caused all manner of security problems. The worst offender
is the register_globals 'feature' which automatically instantiates
PHP variables from the CGI variables that are passed in a GET or POST. While
it does make it easier for programmers to access these values, it also allows
attackers to set the value for any uninitialized variable in the PHP program.
Because PHP is a dynamic language, variables do not necessarily need to be
initialized before they are used and many programs relied on that feature.
When combined with register_globals, this practice leads to easy
exploits.
register_globals has long been turned off by default in PHP, but
there are a huge number of applications that still rely on it. Many PHP
web hosting companies have it turned on because their customers demand it, but
it is very difficult to use the feature correctly. There are PHP modes that
warn of using uninitialized variables, but those warnings typically end up
in a log file somewhere which may not be examined frequently. It is an
extremely dubious feature, but one that PHP creator, Rasmus Lerdorf, seems
to think should have been
left on
by default.
Other poor design choices include the 'magic quotes' feature that gives the
illusion of removing SQL injection issues without actually providing that
protection. Another is the ability of the PHP include directive
to take URL arguments; this has been abused by attackers to pick up their
scripts and have them run on the victim's server. Unfortunately, these
features get into the language and are used making it difficult to remove
them later.
There are various projects to improve upon PHP security, including
Esser's Hardened-PHP, as well
as efforts, such as the
PHP Security Consortium, that seek to educate
people about writing secure PHP code. Unfortunately,
many of the open source PHP projects do not provide good examples
for budding PHP programmers to emulate; they either rely upon
various PHP misfeatures and/or they
were written by programmers without the requisite secure coding
skills.
The existence of these projects (and other similar ones) certainly
provides an indication that the security problem with PHP is
acknowledged by some. PHP proponents tend to take a 'blame the user'
approach that is reasonable in some ways, but fails to recognize some
of the inherent issues with PHP itself. If you target inexperienced
web application programmers, you can hardly be surprised that they
do not have fundamental security skills.
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.
Comments (21 posted)
