11.4 Securing User Data

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.