Web Application Security: Application Error Handling
When an application error occurs, whether due to user input or an internal function, we as conscientious developers want to present an error message that will help the end user correct the problem. However, it is possible to be too helpful with your error handling approach. By providing overly detailed application error messages to your users, you can actually be opening your site to hackers.
Hackers spend the majority of their time performing reconnaissance on a site, slowly gathering multiple pieces of information to determine how a site is vulnerable. Sometimes, it is a seemingly innocuous piece of information in an application error message that provides an attacker with the last piece of the puzzle necessary for him to launch a devastating attack.
User Input Errors
A classic example of providing too much information in an application error message is an authentication failure message on a login screen. At first, it would seem helpful to utilize an error handling method that presents a distinct message indicating that the user ID entered was not found versus indicating that the password was incorrect. And, in fact, it is helpful—but more helpful to an attacker than to a legitimate user.
Imagine that an attacker is trying to break into a Web application. He doesn’t know any existing user IDs or passwords for the site, so he attempts a “brute force” or “dictionary” attack. A list of common user IDs (such as admin, user, and guest) is paired with a list of common passwords (such as password, admin, and Elvis). Every possible combination of the two is tried against the Web site to see if any of them work. If lists of significant size are used, such as actual electronic dictionaries, then the number of possible combinations could run into the billions. Even if an automated tool is used to make the requests, it could take weeks or months to find a match.
If, however, the Web site’s error handling process provides distinct messages that distinguish between an invalid user ID and an invalid password, then the attacker’s job is greatly simplified. Once he comes across a user/password combination that displays an “Invalid Password” application error message, he can stop checking every other user ID in his list. He now knows that the guessed user ID exists in the system, and he can focus on breaking into that account. If his lists of potential users and passwords each contained 5000 items, his task is now reduced from making 25 million requests to a much more manageable 5000 requests. Making 5000 requests could be accomplished in a matter of hours instead of weeks, which means it is much more likely that the attacker could obtain access to the Web site before the site administrator notices the unusual behavior.
Best Practice for User Errors
In this case, the best course of action for the developer working on an error handling approach is to create a single application error message that appears regardless of whether the user ID was not found or the password was incorrect. A good example is: “Invalid user ID or password.”