Every piece of information an attacker receives about a targeted system or application is a valuable weapon. It is the job of application designers and programmers to keep these weapons from the hands of the enemy. Unfortunately, many Web applications cannot handle errors and, as a result, improper error handling occurs.
Because they contain valuable
- Many default messages divulge basic information about a system. This information, which may be presented as part of the message or inferred from the format, aids the attacker in selecting which techniques and exploits will help him gain access.
- Attackers can use error messages to extract specific information from a system.
- Attackers can also use unexpected errors to knock an application off line, creating a denial-of-service attack. These attacks are created by taking advantage of error conditions that consume system resources, such as CPU and disk.
- In a worst-case scenario, unexpected errors can provide an attacker with a buffer or stack overflow condition that sets the stage for an arbitrary code execution.
Example 1: If an attacker attempts to break in by brute force, error messages that include specifics, such as "invalid user name" or "invalid password" are more valuable than if they received a generic message, such as "Login incorrect."
Example 2: Attackers can determine which directories or files exist on a given Web server if it distinguishes between "directory or file not found" and "you are not authorized to see this directory or file." To prevent this, redirect them to the homepage, which will confound some automated attack tools.
Example 3: Errors that supply the full path name to executables, data files and other system assets help the attacker understand how things are laid out behind the firewall. In some cases, they reveal hosts of interest as well.
Example 4: Database errors can be especially helpful to attackers, providing them with host names of internal systems, as well as database, table and field names that can be used to craft SQL injection attacks.
So, what is a programmer to do? Do not rely on the operating system, server, database or other underlying packages to provide error handling. All errors should be handled by code the programmer writes. A well-designed application should include handlers for anticipated error conditions and a failsafe error handler for unanticipated conditions.
Error handlers should capture relevant, detailed information in a secure log for future analysis and present users with a generic error message that does not contain sensitive information. When designing the log file, keep security in mind. It should capture information such as user identifiers, IP addresses, dates and times for pattern analysis.
Having an error log is not enough, however. Someone will need to look at the log and analyze its contents. Many application-level reconnaissance and attacks can be detected by looking for patterns in log files. If a log file shows many error conditions falling through to the default exception handler, it may be time to update the error-handling code to deal with other conditions.
These best practices require the application designer and programmer to think like an attacker. When designing an error message, stop and think about whether it is presenting information the user shouldn't see or that an attacker could use.
Owners of Internet-based services and businesses are at war with those who seek to attack their applications -- don't give them additional information and weapons by saving a little time on error handling!
About the Author This was first published in August 2005
Al Berg, CISSP, CISM is Information Security Director of New York City based Liquidnet (www.liquidnet.com). Liquidnet is the leading electronic venue for institutional block equities trading and the 4th fastest growing privately held financial services company in the US.
This was first published in August 2005