Error Reporting

With PHP security, there are two sides to error reporting. One isbeneficial to increasing security, the other is detrimental.

A standard attack tactic involves profiling a system by feedingit improper data, and checking for the kinds, and contexts, of theerrors which are returned. This allows the system cracker to probefor information about the server, to determine possible weaknesses.For example, if an attacker had gleaned information about a pagebased on a prior form submission, they may attempt to overridevariables, or modify them:

Example #1 Attacking Variables with a custom HTML page

<form method="post" action="attacktarget?username=badfoo&amp;password=badfoo"><input type="hidden" name="username" value="badfoo" /><input type="hidden" name="password" value="badfoo" /></form>

The PHP errors which are normally returned can be quite helpful to adeveloper who is trying to debug a script, indicating such thingsas the function or file that failed, the PHP file it failed in,and the line number which the failure occurred in. This is allinformation that can be exploited. It is not uncommon for a phpdeveloper to use show_source(),highlight_string(), orhighlight_file() as a debugging measure, but ina live site, this can expose hidden variables, unchecked syntax,and other dangerous information. Especially dangerous is runningcode from known sources with built-in debugging handlers, or usingcommon debugging techniques. If the attacker can determine whatgeneral technique you are using, they may try to brute-force a page,by sending various common debugging strings:

Example #2 Exploiting common debugging variables

<form method="post" action="attacktarget?errors=Y&amp;showerrors=1&amp;debug=1"><input type="hidden" name="errors" value="Y" /><input type="hidden" name="showerrors" value="1" /><input type="hidden" name="debug" value="1" /></form>

Regardless of the method of error handling, the ability to probe asystem for errors leads to providing an attacker with moreinformation.

For example, the very style of a generic PHP error indicates a systemis running PHP. If the attacker was looking at an .html page, andwanted to probe for the back-end (to look for known weaknesses inthe system), by feeding it the wrong data they may be able todetermine that a system was built with PHP.

A function error can indicate whether a system may be running aspecific database engine, or give clues as to how a web page orprogrammed or designed. This allows for deeper investigation intoopen database ports, or to look for specific bugs or weaknessesin a web page. By feeding different pieces of bad data, for example,an attacker can determine the order of authentication in a script,(from the line number errors) as well as probe for exploits thatmay be exploited in different locations in the script.

A filesystem or general PHP error can indicate what permissionsthe web server has, as well as the structure and organization offiles on the web server. Developer written error code can aggravatethis problem, leading to easy exploitation of formerly "hidden"information.

There are three major solutions to this issue. The first is toscrutinize all functions, and attempt to compensate for the bulkof the errors. The second is to disable error reporting entirelyon the running code. The third is to use PHP's custom errorhandling functions to create your own error handler. Dependingon your security policy, you may find all three to be applicableto your situation.

One way of catching this issue ahead of time is to make use ofPHP's own error_reporting(), to help yousecure 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 poisoningor modification in other ways. Once you are ready for deployment,you should either disable error reporting completely by settingerror_reporting() to 0, or turn off the errordisplay 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 theerror_log ini directive, and turnlog_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");

add a note add a note

User Contributed Notes 1 note

earlz- -NO SPAM-- at earlz dot biz DOT tm
9 years ago
Note for those of you using OpenBSD and PHP.  The default php.ini has display_errors=off . This is contrary to the PHP default of display_errors=on . If your having trouble seeing errors on OpenBSD make sure to edit your php.ini to have display_errors=on. (I had this problem on OpenBSD 4.4)
To Top