With PHP security, there are two sides to error reporting. One is beneficial
to increasing security, the other is detrimental.
A standard attack tactic involves profiling a system by feeding itimproper data,
and checking for the kinds, and contexts, of the errors which are returned.This
allows the system cracker to probe for information about the server, to determine
possible weaknesses. For example, if an attacker had gleaned information about a
page based on a prior form submission, they may attempt to override variables, or
modify them.
The PHP errors which are normally returned can be quite helpful to a developer who is trying to debug a script, indicating such things as the function or file that failed, the PHP file it failed in, and the line number which the failure occurred in. This is all information that can be exploited.It is not uncommon for a php developer to use show_source(), highlight_string(), or highlight_file() as a debugging measure, but in a live site, this can expose hidden variables, unchecked syntax, and other dangerous information.Especially dangerous is running code from known sources with built-in debugging handlers, or using common debugging techniques. If the attacker can determine what general technique you are using, they may try to brute-force a page, by sending various common debugging strings.
A filesystem or general PHP error can indicate what permissions the web server has,
as well as the structure and organization of files on the web server. Developer written
error code can aggravate this problem, leading to easy exploitation of formerly "hidden"
information.
There are three major solutions to this issue. The first is to scrutinize all functions,
and attempt to compensate for the bulk of the errors. The second is to disable error
reporting entirely on the running code. The third is to use PHP's custom error handling
functions to create your own error handler. Depending on your security policy, you may
find all three to be applicable to your situation.
One way of catching this issue ahead of time is to make use of PHP's own error_reporting(),
to help you secure your code and find variable usage that may be dangerous. By testing your
code, prior to deployment, with E_ALL, you can quickly find areas where your variables may
be open to poisoning or modification in other ways. Once you are ready for deployment, you
should either disable error reporting completely by setting error_reporting() to 0, or turn
off the error display using the php.ini option display_errors, to insulate your code from
probing. If you choose to do the latter, you should also define the path to your log file
using the error_log ini directive, and turn log_errors on.
Example #3 Finding dangerous variables with E_ALL
if ($username) { // Not initialized or checked before usage
$good_login = 1;
}
if ($good_login == 1) { // If above test fails, not initialized or checked before usage
readfile ("/highly/sensitive/data/index.html");
}
|
|
