Error Handling Flaws - Information and How to Fix Tutorial 

Understanding error messages is an important part of web application development and troubleshooting. Error messages provide valuable information to the developer when something goes wrong, allowing them to fix problems with their application and improve the user experience. Unfortunately, when errors are not handled in a secure manner, they can expose sensitive information – sometimes leading to vulnerabilities – to attackers.

What Is Improper Error Handling?

Improper error handling flaws occur when an error message that’s displayed to an end user provides clues about how an application or website operates. Although messages like this can help developers fix problems on their sites, they also show attackers information that they can use to help them break into what should be secured areas. For example, an error message that includes information on the structure of a SQL database table may give attackers everything they need to know in order to carry out a successful SQL injection attack. In some cases, improper error handling can even directly expose the data attackers want, such as passwords.

Ask a Qualified AppSec Expert

Ask in the Community

Ask an Application Security Expert

Improper error handling can lead to serious consequences for any organization, including data leaks and many other exploits. If you’re curious about the risks from improper error handling flaws in your code, the rest of this article explains how to protect against this threat. If you have a more specific question, you can also ask for advice in the Veracode Community, our active forum of application security experts.

Rates of Error Handling Flaws in Software

Unchecked error condition flaws happen at a rate of 5% while uncaught exception flaws happen at a rate of 1%

When Does Improper Error Handling Occur?

Whenever error messages contain details that might be useful to an attacker, that’s evidence of Improper Error Handling. In many cases, improper error handling is a result of using default error handlers. These messages may include detailed information about a file system or even just acknowledge that hidden files and directories exist.

The following are examples of error handling flaws:

  • A message that includes server software version details
  • A message that reveals where a configuration file holding credential information is located
  • An "access denied" message that suggests the existence of hidden files
  • A message that includes a stack trace or other “traceback” details
  • An authentication error message that behaves differently when the user identifier exists than when it does not

Anatomy of an Error Handling Attack

Error handling flaws don't cause harm by themselves. Rather, they allow attackers to uncover vulnerabilities or angles of attack they can use to exploit other system flaws.

This makes error handling attacks a type of reconnaissance, where attackers analyze web applications or other systems for weak points before breaking in and stealing data or causing damage. Another way to think of this is akin to attackers "testing the fence" before selecting the weakest point to break through.

Example of Improper Error Handling

Here is an example SQL error message:

Warning: uncaught exception error in D:pagesauthenticate-new.php on line 238

Because the message includes a file location, attackers have added more details to their knowledge about the website's structure. Worse, the filename "authenticate-new" implies the existence of an "authenticate" as well. If this older file is still on the server and is less secure, attackers may be able to use it to get access they should not have.

Error Handling Attack and Defense Examples

Here’s an OWASP example of a HTTP 404 Not Found error that reveals sensitive information:

Not Found
The requested URL /page.html was not found on this server.
Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g  DAV/2 PHP/5.1.2 Server at localhost Port 80

This error message is generated when the user requests a non-existent URL. In addition to informing the user that an error has occurred and the file can’t be found, the code delivers valuable information about the web server version, OS, modules, and code used. An attacker can use this information to design an attack.

Here’s an example of a database error that offers attackers insights into the system structure. It’s written in PHP:

try {
//print exception message that includes exception message and configuration file location 
catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), '\n';
echo 'Check credentials in config file at: ', $Mysql_config_location, '\n';

This example from demonstrates how an attacker can target a configuration file, such as a Path Traversal weakness. If the attacker is successful in reading the file, this person could gain credentials for accessing the database. At that point, the attacker might replace the actual file with a malicious file. This could result in the application using an arbitrary database.

How to Prevent Improper Error Handling

Many error handling flaws come from default error handlers, which tend to provide more information than is necessary for users. Finding and replacing these error handlers with more secure approaches is an important first step to a secure system. When detailed error messages are required for developers, a secure error handler writes the error details to a log while providing a friendlier message to users – one that avoids revealing sensitive information.

Another important aspect of error handling is consistency. Developers should carry out a detailed code review of error handling logic in their system and ensure proper error handling throughout. OWASP defines proper error handling as that which provides "a meaningful error message to the user, diagnostic information to the site maintainers, and no useful information to an attacker" and recommends writing specific policies for error handling that can achieve these things.

Find and Fix Error Handling Flaws With Veracode

Veracode's cloud-based application security solution offers many opportunities to find and fix security flaws before they can harm an organization's customers and damage its reputation. Here are a few of the ways Veracode can be used to take care of improper error handling flaws.

Web-Application Scanning

Web-application scanning, also known as dynamic analysis, is a type of test that runs while an application is in a development environment. Dynamic analysis is a great way to uncover error-handling flaws. Veracode's dynamic analysis scan automates the process, returning detailed guidance on security flaws to help developers fix them for good.

Static Analysis

Unlike web-application scanning, static analysis looks at the code of an application without having to run it. While this process often requires access to the application's source code, Veracode's binary static analysis tool scans the binary (or executable) code instead, meaning customers can find flaws in parts of their application to which they don't have source code.

Application Analysis and Developer Enablement

Veracode's application analysis products are modular, with a centralized cloud-based platform that makes it easy for developers to view their entire application's security situation in one place. Our security solutions can also be implemented in an organization's existing application development workflow with one of our more than 40 integrations. We use IDEs and other application development software.

Learn More About Secure Code Best Practices

Veracode is more than just a software security scanning system. Our cloud-based tools provide developers with in-context guidance that teaches them best practices at the same time making software more secure. We also provide eLearning solutions, such as expert-led online workshops and self-paced training. Check out our catalog of application security practices today or download our free handbook on secure coding best practices to get started.

Secure Coding Handbook

A developer’s guide to delivering safer code faster in the cloud and on premises.

Get the Handbook