Programming PHP with Security in Mind

Writing code that prevents some common types of attacks is rather easy—here are some guidelines.

From time to time, you will find a
security advisory about some major web application on security
mailing lists. Most of the time, the problem is fixed easily. The
errors often occur because the author had five minutes to do his
application while his boss was yelling at him, or was distracted
when developing it or simply did not have enough practice in
programming secure web applications.

Writing a secure web application is not an easy task, because
the real problem is not a matter of knowledge but one of practice.
It is a good idea to keep some tips in mind when programming. To
help memorize them, you should understand how and why they are so
important. Then you can start to change your programming practices
in the future. Knowledge of the most common threats and respective
modes of attack can go a long way toward increasing
security.

This article provides a basis for understanding secure
programming with PHP and gives a broader view of the subject. You
should keep in mind that these guidelines identify only the most
common threats and how to avoid them, reducing the risk of security
compromise at the same time.

The basic rule for writing a secure application is:
never trust user input. Poorly validated user
input constitutes the most severe security vulnerabilities in any
web application. In other words, input data should be considered
guilty unless proven innocent.

Global Variable Scope

PHP versions prior to 4.2.0 registered by default all kinds
of external variables in the global scope. So no variable could be
trusted, whether external or internal.

Thankfully, since version 4.1.0, PHP has deprecated
register_globals. This means that GET, POST, Cookie, Server,
Environment and Session variables are no longer in the global scope
anymore. To help users build PHP applications with register_globals
off, several new special arrays exist that are automatically global
in any scope. They include $_GET, $_POST, $COOKIE, $_SERVER, $_ENV,
$_REQUEST and $_SESSION.

If the directive register_globals is on, do yourself a favor
and turn it off. If you turn it off and then validate all the user
input, you made a big step toward secure programming. In many
cases, a type casting is sufficient validation.

Client-side JavaScript form checks do not make any
difference, because an attacker can submit any request, not only
one that is available on the form. Here is an example of what this
would look like:

Most PHP applications use databases, and they use input from
a web form to construct SQL query strings. This type of interaction
can be a security problem.

Imagine a PHP script that edits data from some table, with a
web form that POSTs to the same script. The beginning of the script
checks to see if the form was submitted, and if so, it updates the
table the user chose.

If you do not validate the variable $table that came from the
web form, and if you do not check to see if the
$update_table_submit variable came from the form (via
$POST['update_table_submit']), you can set its
value via GET to whatever you want. You could do it like this:

A simple validation for the $table variable would be to check
whether its content is alphabetical only, or if it is only one word
(if (count(explode("",$table)) { ... }).

Calling External Programs

Sometimes we need to call external programs (using system(),
exec(), popen(), passthru() or the back-tick operator) in our PHP
scripts. One of the most dangerous security threats is calling
external programs if the program name or its arguments are based on
user input. In fact, the PHP manual page for most of these
functions includes a note that warns: “If you are going to allow
data coming from user input to be passed to this function, then you
should be using escapeshellarg() or escapeshellcmd() to make sure
that users cannot trick the system into executing arbitrary
commands.”

Imagine the following example:

<?php
$fp = popen('/usr/sbin/sendmail -i '. $to, 'w');
?>

The user can control the content of the variable $to above in
the following manner:

I think that there are too many coincidences (same sub-topics and code snippets) with an article(http://www.developer.com/lang/archives.php), published a year prior to this one. It is just not honest not to give credit!

Most articles about security and PHP cover the same topics.
Just because they both gave the "sendmail" example it doesn't really mean anything. But everyone can read both articles and judge for themselves. :-)

It's also very common for people to introduce some short name for a long name so they don't have to write down the endless name all the time. So even if it's not officially used for Cross-Side-Scripting, doesn't mean he's inventing. He's just applying some writing style that is rather common. Yeah, I read books :P