When it comes to security issues, it's important to note that in addition to actual platform and operating system security issues, you also need to ensure that you write secure applications. When writing PHP applications, apply the following seven habits to ensure your application has the best possible security:
• Validate input
• Protect the file system
• Protect the database
•Protect session data
•Protect cross-site scripting (XSS) vulnerabilities
•Verify form post
•Protect against Cross-Site Request Forgeries (CSRF) Protect
Validate input
When it comes to security issues, validating your data is the most important habit you can adopt. And when it comes to input, it's very simple: don't trust the user. Your users may be excellent, and most of them may use the application exactly as expected. But wherever there is an opportunity for input, there is also a high probability of very bad input. As an application developer, you must prevent your application from accepting incorrect input. Careful consideration of the location and correct value of user input will allow you to build a robust, secure application.
Although file system and database interaction will be covered later, Listed below are general validation tips that apply to various validations :
• Use white Values in the list
• Always revalidate limited options
• Use built-in escaping functions
• Validate correct data types (like numbers)
Values in the whitelist (White- listed value) is the correct value, as opposed to the invalid black-listed value (Black-listed value). The difference between the two is that typically when validating, the list or range of possible values is smaller than the list or range of invalid values, many of which may be unknown or unexpected values.
When doing validation, remember that it is often easier to design and validate the values your application allows than to protect against all unknown values. For example, to limit a field value to all numbers, you need to write a routine that ensures that the input is all numbers. Do not write routines that search for non-numeric values and mark them as invalid when they are found.
Securing File Systems
In July 2000, a Web site exposed customer data stored in files on the Web server. A visitor to the Web site used the URL to view a file containing data. Although the file was misplaced, this example highlights the importance of protecting the file system from attackers.
If a PHP application manipulates a file and contains variable data that the user can enter, carefully check the user input to ensure that the user cannot perform any inappropriate actions on the file system. Listing 1 shows an example of a PHP site that downloads an image with a specified name.
List 1. Download file
Copy code The code is as follows:
if ($_POST['submit'] == 'Download') {
$file = $_POST['fileName'];
header("Content-Type: application/x-octet-stream ");
header("Content-Transfer-Encoding: binary");
header("Content-Disposition: attachment; filename="" . $file . "";" );
$fh = fopen($file, 'r');
while (! feof($fh))
{
echo(fread($fh, 1024));
}
fclose( $fh);
} else {
echo("<");
echo("title>Guard your filesystem" );
echo("
");
}
As you can see, the more dangerous script in Listing 1 will process all files that the web server has read access to, including files in the session directory (see "Securing session data") and even some system files ( For example /etc/passwd). For demonstration purposes, this example uses a text box where the user can type a filename, but the filename can easily be provided in the query string.
Simultaneous configuration of user input and file system access is dangerous, so it is best to design your application to use a database and hide generated filenames to avoid simultaneous configuration. However, this doesn't always work. Listing 2 provides a sample routine for validating file names. It will use regular expressions to ensure that only valid characters are used in file names, and specifically checks for dot characters: ..
Listing 2. Checking for valid filename characters
Copy code The code is as follows:
function isValidFileName($file) {
/* don't allow .. and allow any "word" character / */
return preg_match('/^(((?:.)(?!.)) |w)+$/', $file);
}
Protect database
In April 2008, the Bureau of Prisons of a certain state in the United States was querying SQL column names were used in the string, thus exposing confidential data. This breach allowed a malicious user to select which columns to display, submit the page, and obtain the data. This leak shows how users can perform input in ways that application developers could not have anticipated, and demonstrates the need to defend against SQL injection attacks.
Listing 3 shows a sample script that runs a SQL statement. In this case, the SQL statement is a dynamic statement that allows the same attack. The owner of this form may think the form is safe because they have restricted the column names to select lists. However, the code misses one last tip about form cheating — just because the code limits the options to a drop-down box doesn't mean that someone else can't post the form with the required content (including the asterisk [*]).
Listing 3. Execute SQL statement
Copy code The code is as follows:
SQL Injection Example
if ($_POST['submit'] == 'Save') {
/* do the form processing */
$link = mysql_connect ('hostname', 'user', 'password') or
die ('Could not connect' . mysql_error());
mysql_select_db('test', $link);
$ col = $_POST['col'];
$select = "SELECT " . $col . " FROM account_data WHERE account_number = "
. $_POST['account_number'] . ";" ;
echo '' . $select . '
';
$result = mysql_query($select) or die('' . mysql_error() . '
' );
echo '';
while ($row = mysql_fetch_assoc($result)) {
echo '';
echo '' . $row[$col] . ' | ';
echo '
';
}
echo '
';
mysql_close($link );
}
?>
