Team LiB
Previous Section Next Section

Style and SecurityLogging

Unfortunately, there is no way that any single chapter, or book for that matter, can address every potential security hole that could be encountered. In this chapter, I have introduced you to some of the most common practices of hackers, but it is by far incomplete. I have also introduced you to some stylistic things that can be done to make your scripts more secure. In this section, I will introduce the single biggest thing that can be done to keep your website secureerror logging and reporting.

It may not seem like it, but appropriately logging unintended behavior of your scripts is the single best thing you can do to keep your site secure. This is because, unless you know something is going astray, how can you even begin to correct the issue? Just as a hacker will attempt to feed your scripts bogus information to gather intelligence about the function of your website, you as the programmer must also use the PHP error-logging facilities to gather the same intelligence about the weaknesses of your scripts. In this section, we'll look at the error-logging facilities provided by PHP.

From a point of security, the point of error logging is to deny access to error information to a malicious user while providing that same information to you as the developer of the script. Without any indications of your scripts functioning in unintended ways through the display of error messages, it can become very difficult for a malicious user to make any real headway in hacking your scripts. Meanwhile, because a log is being kept, you as the developer can see the hacking attempts made by the malicious user and correct any potential security holes before they are exploited.

In terms of implementation, error logging in PHP can be as simple or as complex as you would like it to be. PHP itself offers a wide range of functions and options related to how errors are both dealt with and logged. By default, all errors that are of a sufficient error level (as dictated by the error_reporting configuration directive) will be displayed to the browser. Anyone who has programmed for any length in PHP has seen them before:

Notice: Undefined index: content in
         /usr/local/apache/htdocs/index.php on line 22

These error messages are useful to you as a developer as you write your script; however, they are even more useful to a hacker looking for weaknesses. Rather than displaying these errors to the browser, in anything other than a development environment these such errors should be logged instead of displayed. To enable logging, use the log_errors configuration directive. Alternatively, the display_errors configuration directive may also be used to completely remove any errors from being displayed.

When error logging is enabled in PHP, where exactly the error will be logged depends on the configuration of PHP. By default, with logging enabled, PHP will record any errors within the Web server's error log. However, this behavior can also be changed by changing the value of the error_log configuration directive to point to a file that should be used to write error messages. When specifying the error_log configuration directive, the special filename syslog may also be used, indicating that PHP should log all errors to the operating system's error-logging facilities. In Unix-based systems, this would be the standard syslog, whereas in Windows-based systems, the event log would be used.

Logging Custom Error Messages

Now that you are more familiar with the error-logging mechanisms provided by PHP, let's introduce our first error-logging related functionthe error_log() function:

error_log($message [, $message_type [, $dest [, $extra]]]);

Although PHP will always log error messages, this function is used to manually insert an error message into the log. It is very useful for including extra information into an error log based on the logic of your application (the user entered the wrong username/password) although such situations do not actually cause an error in PHP itself.

Looking at the prototype for the error_log() function, the first parameter, $message, is the message to record in the error log. The optional second parameter, $message_type, determines where the message will be logged and is one of the following values (see Table D.1).

Table D.1. $message_type Constant Values


Log $message to the facility specified by the error_log configuration directive.


Email $message to the email address specified by the $dest parameter. Any additional email headers can be specified in the $extra parameter.


Log $message to the filename specified by the $dest parameter.


It is not a typo that the $message_type constant value of 2 was ignored in Table D.1. In PHP version 3.0, this value was used to send a remote debugger messagesomething that no longer exists in PHP 4 and PHP 5.

As you can see, the final two optional parameters, $dest and $extra, are used under different circumstances, depending on the value provided for the $message_type parameter.

In terms of security and good programming practice, the error_log() function, or a similar facility, should be used in any serious application to record nonfatal error conditions. These conditions can be an invalid username/password combination, a corrupt or invalid file where one was expected, or anything else that could indicate a malicious user is attacking your system. Of course, logs are only as useful as the amount of attention spent paying attention to them. Thus, as a follow up to your solid error-logging practices, make sure you make an effort to review your error logs to ensure that any potential problems or hack attempts are dealt with properly.

    Team LiB
    Previous Section Next Section