This article is also available as a TechRepublic download.

How improper error handling contributes to data leakage

 

Improper error handling is caused by providing too much information to the user when an error occurs in an application or the underlying infrastructure. The following is a partial list of content that often finds its way onto the screen of a user or attacker:

  • Revealing stack traces — Stack traces provide programmers with detailed information about what programs or functions had been called before the error occurred. This same information provides a computer criminal with names of functions, objects, and other information relevant to designing an attack against the system reporting the error.
  • Providing system names — One of the first steps in planning an attack is to footprint the target network. This process results in a map of systems (by name), IP addresses, location and configuration of network services, etc. Allowing error messages to return some or all of this information makes an attacker’s job much easier.
  • Verification of the existence of a file — If a user who is not authorized to access a file attempts to do so, the error message returned often informs her that she is not authorized to access that resource. If she’s an attacker trying to locate files known to contain sensitive information, the error message has just provided her with a positive hit.
  • Informing the user whether the user ID or password is incorrect after a failed login — A failed login attempt could be caused by an incorrect ID or an incorrect password. This is valuable information to an attacker who has launched a brute force attack against a critical asset.
  • Exposing database, field, and table names — Information about databases is valuable when planning activities like a SQL Injection attack.
  • Information about intrusion defense infrastructure — Verbose error messages can come from any device or system. They can even provide the information necessary to circumvent IDS and IPS systems.

Reducing the risk

Mitigating the risk associated with improper error messages is not that difficult. It does take constant vigilance to ensure that the holes through which information about your network leaks are plugged — in both new and existing applications. Here are a few suggestions:

  • Capture and process all application errors. Never assume that default error messages in application environments provide adequate protection for sensitive information about your enterprise. This includes customization of Web server error pages.
  • Error messages sent to the users’ screens should contain information useful for support or recovery without providing environmental information. For example, you might provide the message shown in Figure A. The error code, 500-25, should mean something to your support and programming teams, but nothing to the user or potential attacker.

Figure A
Error message
  • Write necessary detailed error information, used for error debugging, to a secure location. Secure locations include the Application Event Log or some other secure file with limited access.
  • OWASP recommends using tools like WebScarab to force applications to generate errors. This is one way to ensure that a “best effort” approach is taken to identify any errors that might help compromise the target system or the network.
  • Each application should include a standard error-handling framework to handle exceptions. Developers should not have to reinvent exception-handling routines each time they develop an application. Further, the framework should serve as a guideline to assist development teams in their efforts to provide meaningful messages while hiding sensitive system or network information.

The final word

Providing useful error messages is necessary to ensure that your users and your programmers receive the information needed to restore service as soon as possible. Just make sure you don’t also help an attacker in the process.

There’s a great article at the OWASP Web site that describes how a fictional hacker is able to obtain a great deal of information about a target system using information contained in a single error message. I strongly recommend you read this short narrative. It will give you a clear sense of the dangers of verbose error messages.