The clean(
)
function
in the include file
db.inc makes user input secure. The function is
shown in Example 11-3, and it takes two parameters:
the user $input
and the maximum length
$maxlength
that is expected. It returns the clean
user data.
The clean( )
function uses the PHP library string
function substr(
)
to
reduce the length of the $input
to its desired
maximum. It then uses the PHP library function
EscapeShellCmd(
)
to insert backslash characters before selected characters—such
as semicolons, backslashes, greater-thans, and less-thans—so
that their special meanings in Unix shells are nullified or
escaped. These two steps are usually sufficient
to ensure that users cannot maliciously add extra clauses to SQL
queries and cannot manipulate other MySQL library functions.
Never trust user input or network data.
You should preprocess all user data by escaping special shell
characters and ensuring that the data does not exceed a maximum
length. A function such as clean( )
in our
db.inc include file is useful for this task.
The automatic initialization of variables by the PHP engine also
presents a minor security risk. The engine initializes variables in a
certain order (defined in PHP’s configuration file
php.ini
), which presents the possibility that a
variable can be initialized twice, with the second value overwriting
the first. For example, by default, the PATH
environment variable, which tells the PHP engine where to look for
programs, is one of the first that is initialized. If the user passes
through a parameter with the name PATH
, the
user’s value will overwrite the system default. This
can be undesirably exploited.
A simple solution is to turn off the automatic initialization of
variables by setting register_globals
=
off
in the
php.ini configuration file. However, if you do
disable automatic initialization, you can still access the user data
by associative array access. Any user
variables passed through with the
GET
method are elements of the
array $HTTP_GET_VARS
. For example, to access the value of a
user-supplied parameter message
, you can access
the element of the array as
$HTTP_GET_VARS["message"]
.
We don’t discuss the <form>
POST
method, environment variables, server
variables, or cookies in detail in this chapter. However, these
variables can be found in the following arrays:
Parameters passed with the <form>
POST
method are found in
$HTTP_POST_VARS
.
Environment
variables can be found in the array
$HTTP_ENV_VARS
.
Session variables can be found in the
array $HTTP_SESSION_VARS
.
Cookie variables can be found in the array
$HTTP_COOKIE_VARS
.
Server variables can be found in the array
$HTTP_SERVER_VARS
.
You should also be careful how you use data that is received from the
browser. For example, it is unwise to use
the price of an item from a <form>
widget to
calculate an invoice; even if the price is hidden or read-only, the
user can still change it by modifying the
<form>
or authoring a URL. The correct
approach is to verify the price against the database before
calculating the invoice. Similarly, don’t embed SQL
in HTML—even if it is hidden—because the user can browse
the HTML source, figure out the database structure, and modify the
statements.