While this error handling approach does not deliver much information, it may be enough to help him launch a successful attack. Furthermore, it is not information that a legitimate user really needs.
Death by a Thousand Cuts
Even a small amount of data leakage occurring via error handling can be extremely dangerous. It is rare that a single error message contains all the information that an attacker needs to compromise the system. Instead of a single, deadly “silver bullet”, a much more common attack is one that precipitates a “death by a thousand cuts.” It is the sum of the many tiny, individual bits of information provided by improper application error handling that provides an attacker with enough knowledge to successfully exploit the security weaknesses of the system.
Best Practice for Internal Errors
One solution, of course, is to display a very generic “An error occurred” message for anything that could possibly go wrong in the system. There is no detail to the application error message and no distinctiveness either. There is no information that an attacker could use. While this approach to error handling is very secure, it is not very helpful to the developers or technical support staff. If a user encounters an application error, there is no useful information that he can provide the application owners that would help to reproduce or debug the problem.
The error handling approach that provides the best mix of security and functionality is the issue tracking technique. Whenever an application error occurs, a detailed log is made of the error conditions. This log is assigned a unique issue ID and stored someplace securely on the server, such as a database or directory that cannot be accessed via a Web browser. An error message that contains the issue ID is returned to the user. The user can report the issue ID to technical support, who can reference the detailed log from the secure location on the server. This error handling approach provides detailed information to the application owner, while keeping it from the user and any potential attackers.
Issue tracking also satisfies the condition that errors not be distinct based on the type of application error. Every error handling message is unique, since every error will have a unique tracking ID. Since no pattern can be discerned from the responses, however, this technique is just as secure as providing exactly the same error message for any error situation. To provide an additional measure of security during error handling, use a completely random number or globally unique identifier (GUID) for the issue tracking ID rather than a sequential number. This will prevent attackers from performing “social engineering” attacks by contacting technical support with easily-guessed tracking numbers.
Conclusion: A Simple Solution
It can be difficult to determine the correct amount of feedback to present to a user in the event of an application error. If the developer tries to be as helpful as possible with his error handling approach, it can backfire on him, since information that is helpful to a user can also aid an attacker in attacking the system. On the other hand, if the developer is overly vague, then it is much more difficult to repair the application error since the user won’t have any data to provide the developers or the technical support team.
For a simple solution, follow these guidelines when creating application error messages: When the application error is due solely to invalid user input, such as an invalid password, then the application should present a generic and non-distinct error message. When the error occurs in the application code, such as a database error, then the application should provide a generic message containing a tracking number. The tracking number can then be used by technical support to help resolve the issue.
By following these guidelines, you can thwart the attempts of attackers who try to gain knowledge of your application through its error handling messages.