This error handling message is just helpful enough to let a legitimate user know that he needs to re-enter his login credentials, while not providing any additional information that could help an attacker perform a brute force attack.
As we have seen, it is important not to provide too much detail when formulating error handling procedures for users. It is even more important to withhold details when an error occurs in the application itself. There are many possible reasons why this might happen: a required database or Web service might be unavailable; a component license might have expired; or it might even just be a bug in the code. Regardless of the cause, it is vital to never reveal the specifics of the application error to the user.
Attackers thrive on specifics. By allowing a detailed component error to be displayed, a database error for example, an attacker might be able to determine the type of database being used, its version, the operating system on which the database is running, the Web server being used, possibly even some of the source code of the Web application. All of these pieces of data are ammunition that the attacker can use to attack the Web site. For example, if the error handling method allows the attacker to find that the database being used is Microsoft SQL Server 2000, the very next thing he will do is search the Internet for known security vulnerabilities in Microsoft SQL Server 2000. Some application error messages even reveal the complete or partial path of the offending file, or name the offending row or column in a table, in an attempt to help a user track down the origin of the problem. This form of application error handling will give an attacker more information that can be used for malicious purposes.
Many Web sites attempt to prevent this information disclosure and still be helpful to the user by displaying a friendly application error message with the component error code embedded in it. For example, “An error has occurred. Please contact tech support and reference the error code 123-456-789.” However, this error handling method is not much better than before, and for the same reason. The attacker will simply search for “123-456-789.” Chances are good that documentation for the application error code exists someplace on the Internet, and if it does, an attacker will find and use it.
Custom Error Codes
Some Web applications create their own internal error codes to display to users as part of the error handling process. If any application error occurs in the database layer, for instance, they display a message like “Please contact tech support and reference the error code 01.” If any application error occurs in a licensing component, the message changes to reference the error code “02.” This error handling method does provide a degree of security over previous methods, since the meanings of the internal codes will not be found in a search of the Internet. Unfortunately, this form of error handling is still unsafe.
It is the distinctiveness of the application error, rather than its content, that is the security flaw in this case. Just as in the error handling method discussed earlier, wherein the attacker took advantage of the difference between the invalid-user response and the invalid-password response; a clever attacker will notice that some of his attacks return error code “01,” and some return error code “02.”