Extracting Information from Custom Errors
Understanding information provided by application errors
Software developers often use error handling and validation mechanisms to prevent the application from crashing when an unexpected event occurs. In those situations custom errors are habitually returned to the user to indicate that something wrong happened (without providing full details). Let’s see how this information can be used by the attacker to collect more information about the system and find out if the attack was successful.
Custom Application Error
Custom error messages verbosity should be sufficient to help the programmer identify the source of the problem. At the very least, the error will contain information to help the user. This also means that they can contain enough details to help the attacker generate a valid query. If it is not the case, the information provided could possibly be used in later steps of the attack. As shown in the example below, even a message containing a low level of details can help the attacker.
Malicious input.
5 OR 1=1
Query generated.
SELECT * FROM products WHERE id=5 OR 1=1
Custom error message.
Error - Only 1 product expected.
In this case we can suppose that a simple validation was made to verify only one record is returned by the query. The error returned seems to indicate that the injected condition was executed. Further testing will validate or disprove this assumption. It should also be mentioned that in some rare situations, a full stack trace or database/API error message can be returned to the end user by custom application errors.
Error Prevention
When vague error messages are returned it can be difficult to tell if the crafted SQL segment was sent to the database or if it only failed the validation process. In those cases, the error does not really provide hints to the attacker and the testing will fall down to two possible scenarios. The first is to use alternative injection strings in order to escape validation filters. The second is to use inference testing and/or blind SQL injection techniques such as time-based attacks.
Generic Errors
As mentioned earlier, the application could return a custom error page indicating the details of the unexpected behavior, but it could also be presented in a generic error page. Some API and web servers have default error reporting templates. If the application has not been configured to change generic error page, this is probably where the error will be shown.
