Apache Security - Ivan Ristic [109]
if (count($_POST) != 0) {
// some POST requests contain parameters in the URI
if (strpos($request, "?") = = false) $request .= "?";
else $request .= "&";
$count = 0;
foreach($_POST as $name => $value) {
if ($count != 0) $request .= "&";
$request .= urlencode($name) . "=" . urlencode($value);
$count++;
}
}
$request .= $_SERVER["SERVER_PROTOCOL"];
// send the parameters to Apache through notes
apache_note("x_username", $username);
apache_note("x_sessionid", $sessionid);
apache_note("x_request", $request);
// set an environment variable to trigger
// conditional logging
apache_setenv("x_log", "true");
}
Sending a message from the application to the logging module can be useful. This can be done through a warning note:
function warn_apache($warning) {
apache_note("x_warning", $warning);
}
Recommended log format
Finally, we arrive at our new log format:
LogFormat "%h %l %{x_username}n %t \"%{x_request}n\" %>s %b \"%{Referer}i\" \
\"%{User-Agent}i\" %{UNIQUE_ID}n %T %D %{x_sessionid}n %{x_warning}n \
%{error-notes}n" apptrack
Note the following:
The application username takes the place of the HTTP-based username previously obtained via %u.
The original request line (obtained via %r) is replaced with our request line (via %{x_request}n), which will include the POST data, too.
We use %T 0 for Apache 1 and %T %D for Apache 2. Since Apache 1 does not provide the request processing time in seconds, we will use a zero instead of the actual value to avoid having two log formats. The log processing software must be able to handle the case where this information is unavailable.
We use the new log format together with a conditional logging directive to avoid having bogus lines in the log file:
# log only requests that have the extra PHP-supplied information
CustomLog /var/www/logs/special_log apptrack env=x_log
Alternative integration method
If you cannot take advantage of the Apache notes mechanism and the PHP integration (you may not be running PHP as a module, for example), the alternative is to use mod_security to recover the POST request body (it will create the x_request note when configured to do so) and to use response headers to transport the information out of the application. In the application code, send out the session identifier and the username, using headers x_sessionid and x_username. These headers can be logged with %{x_sessionid}o and %{x_username}o, respectively.
header("x_sessionid: $sessionid");
header("x_username: $username");
You will not be able to send a warning from the application using response headers though. Outgoing headers will be visible to the client, too, and using them for a warning may result in revealing critical information to an attacker.
Log Manipulation
Apache does a good job with log format definition, but some features are missing, such as log rotation and log compression. Some reasons given for their absence are technical, and some are political:
Apache usually starts as root, opens the log files, and proceeds to create child processes. Child processes inherit log file descriptors at birth; because of different permission settings, they would otherwise be unable to write to the logs. If Apache were to rotate the log files, it would have to create new file descriptors, and a mechanism would have to exist for children to "reopen" the logs.
Some of the Apache developers believe that a web server should be designed to serve web pages, and should not concern itself with tasks such as log rotation.
Of course, nothing prevents third-party modules from implementing any kind of logging functionality, including rotation. After all, the default logging is done through a module ( mod_log_config) without special privileges. However, at the time of this writing no modules exist that log to files and support rotation. There has been some work done on porting Cronolog (see Section 8.2.2.2 in the Section 8.2.2 section) to work as a module, but the beta version available on the web site has not been updated