Bugtraq mailing list archives

Re: A Study In Scarlet - Exploiting Common Vulnerabilities in PHP Applications


From: Chris Adams <chris () improbable org>
Date: Mon, 02 Jul 2001 15:36:06 -0700

on 2001-07-02 07:37, Shaun Clowes at shaun () securereality com au wrote:

SecureReality is pleased to announce the release of our new paper entitled
'A Study In Scarlet - Exploiting Common Vulnerabilities in PHP

You listed many common mistakes, which is good, but I think your conclusion
("I contend that it is very hard to write a secure PHP application (in the
default configuration of PHP), even if you try.") is somewhat off-target. It
really should be something like "PHP does not prevent bad programmers from
writing insecure code", particulary if you consider "even if you try" to
imply more than the most cursory effort.
 
For example, consider how many of these problems disappear if you correct
three common mistakes:
    - failure to place private files outside of the webroot
    - failure to check user input
    - failure to structure a program to prevent people from calling code in
creative ways[1]

We've all seen these before.

It's really quite easy to write a  secure application in PHP - assuming you
have the necessary security literacy, which is the real issue. PHP is no
more vulnerable to these problems than any other language - problems like
these have been reported in everything from ASP to Zope - and in fact makes
it easier to protect against them than many environments[2]. It's also no
secret that much of the PHP code available in various opensource projects is
not particularly well-written.

Since all of these problems are quite easy to avoid, what we really need is
to improve the security literacy of the average programmer. Without at least
basic security awareness, the odds that a programmer won't remember to do
something trivial like declaring critical variables but will handle the less
obvious challenges correctly approach zero.

Chris

[1] e.g. PHP provides include_once() and require_once() for this purpose -
if bar.php depends variables which are defined in foo.php, it should have a
require_once("foo.php") at the top. Similarly, rather than using the
something like include("$configPath/file"), you should either set
include_path or use constants, which can't be set by attackers.

[2] e.g. magic_quotes_gpc helps prevent an entire class of attacks and there
are a number of validation functions which are quite easy to use, hopefully
enough so that they will actually be used.


Current thread: