When an application error occurs, whether due to user input or an internal function, software developers want to present an error message that will help the end user correct the problem. But by providing overly detailed application error messages, you can actually be opening your site to hackers. Sometimes, it is a seemingly innocuous piece of information in an application error message that provides an attacker with the last bit of information he needs to launch a devastating attack. Here are some practical tips for ensuring that you're providing the right amount of information to the right people.

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, 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 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" 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, making it 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." This error handling message is just helpful enough to let a legitimate user know that he needs to re-enter his login credentials, while

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine