Are detailed exception/error messages a security risk?

Question

I currently check every GET and POST variable with isset() and throw exceptions when isset() returns false.

Example 1:

if(!isset($_GET['some_var']))
    throw new Exception('GET variable [some_var] is not set.');

$someVar = $_GET['some_var'];

Example 2:

if(!isset($_GET['some_num']))
    throw new Exception('GET variable [some_num] is not set.');

if(!ctype_digit($_GET['some_num']))
    throw new Exception('GET variable [some_num] is not a number.');

$someNum = $_GET['some_num'];

In my production application I have a global exception handler that posts exceptions and errors to a log file and then redirects to a generic apology page.

Is this an okay practice? Are descriptive exception and error messages such as the ones above security risks (is it possible that a hacker would be able to read the exception notice and then use that information to manipulate my scripts)?

Thanks!

Answer 1

"is it possible that a hacker would be able to read the exception notice and then use that information to manipulate my scripts?"

Maybe.

Typically, you want to give the least amount of information possible to the end user in an error condition. In this case, if you tell someone a particular get variable doesn't exist, then they might try supplying random values to that variable to see how the app behaves.

Of course, you also have to balance this against the needs of your real users. If the variable is one that they would normally have control over, then giving the response about a problem with the value is perfectly acceptable.

Answer 2

Displaying detailed errors to a user can be a security risk. Since in this case, they're only being written to a log file and the only data the user gets is a generic page which reveals nothing, you can be as descriptive as you like and you reveal nothing unless the log is compromised.

Answer 3

Usually it is considered insecure to print out PHP system error messages on a production server instead of silently logging it.
Though I can't find anything dangerous in the generic apologies page.

Answer 4

Logging errors and suppressing output is exactly what you should be doing. Error reporting can be nasty..

In OWASP top 10 for 2007 there is Information Leakage and Improper Error Handling, however this was removed in 2010. By setting dispaly_errors=On in your php.ini you become vulnerable to CWE-200. The full path of your web application will be divulged to the attacker. To make matters worse, by having error reporting enabled it makes it easier to find SQL injection by looking for sql error messages.

When combining this on a PHP/MySQL application you can perform a very serious attack

$vuln_query="select name from user where id=".$_GET[id];

If

http://localhost/vuln_query.php?id=1 union select "<?php eval($_GET[e])?>" into outfile "/path/to/web/root/backdoor.php"

Which makes this full query:

select name from user where id=1 union select "<?php eval($_GET[e])?>" into outfile "/path/to/web/root/backdoor.php"

I would make sure display_errors=Off and that file FILE privileges have been revoked to your web application's MySQL user account.