Critical database server error message vulnerabilities were identified in the web application, indicating that an unhandled exception was generated in your web application code. Unhandled exceptions are circumstances in which the application has received user input that it did not expect and does not know how to handle. When successfully exploited, an attacker can gain unauthorized access to the database by using the information recovered from seemingly innocuous error messages to pinpoint flaws in the web application and to discover additional avenues of attack. Recommendations include designing and adding consistent error-handling mechanisms that are capable of handling any user input to your web application, providing meaningful detail to end-users, and preventing error messages that might provide information useful to an attacker from being displayed.
The most common cause of an unhandled exception is a failure to properly sanitize client-supplied data that is used in SQL statements. They can also be caused by a bug in the web application’s database communication code, a misconfiguration of database connection settings, an unavailable database, or any other reason that would cause the application’s database driver to be unable to establish a working session with the server. The problem is not that web applications generate errors. All web applications in their normal course of operation will at some point receive an unhandled exception. The problem lies not in that these errors were received, but rather in how they are handled. Any error handling solution needs to be well-designed, and uniform in how it handles errors. For instance, assume an attacker is attempting to access a specific file. If the request returns an error File not Found, the attacker can be relatively sure the file does not exist. However, if the error returns “Permission Denied,” the attacker has a fairly good idea that the specific file does exist. This can be helpful to an attacker in many ways, from determining the operating system to discovering the underlying architecture and design of the application.
The error message may also contain the location of the file that contains the offending function. This may disclose the webroot’s absolute path as well as give the attacker the location of application “include” files or database configuration information. A fundamental necessity for a successful attack upon your web application is reconnaissance. Database server error messages can provide information that can then be utilized when the attacker is formulating his next method of attack. It may even disclose the portion of code that failed.
Be aware that this check is part of unknown application testing which seeks to uncover new vulnerabilities in both custom and commercial software. Because of this, there are no specific patches or remediation information for this issue. Please note that this vulnerability may be a false positive if the page it is flagged on is technical documentation relating to a database server.
The severity of this vulnerability depends on the reason that the error message was generated. In most cases, it will be the result of the web application attempting to use an invalid client-supplied argument in a SQL statement, which means that SQL injection will be possible. If so, an attacker will at least be able to read the contents of the entire database arbitrarily. Depending on the database server and the SQL statement, deleting, updating and adding records and executing arbitrary commands may also be possible. If a software bug or bug is responsible for triggering the error, the potential impact will vary, depending on the circumstances. The location of the application that caused the error can be useful in facilitating other kinds of attacks. If the file is a hidden or include file, the attacker may be able to gain more information about the mechanics of the web application, possibly even the source code. Application source code is likely to contain usernames, passwords, database connection strings and aids the attacker greatly in discovering new vulnerabilities.
From a development perspective, the best method of preventing problems from arising from database error messages is to adopt secure programming techniques that prevent problems that might arise from an attacker discovering too much information about the architecture and design of your web application. The following recommendations can be used as a basis for that.
- Stringently define the data type (for instance, a string, an alphanumeric character, etc) that the application will accept.
- Use what is good instead of what is bad. Validate input for improper characters.
- Do not display error messages to the end user that provide information (such as table names) that could be utilized in orchestrating an attack.
- Define the allowed set of characters. For instance, if a field is to receive a number, only let that field accept numbers.
- Define the maximum and minimum data lengths for what the application will accept.
- Specify acceptable numeric ranges for input.
For Security Operations:
The following recommendations will help in implementing a secure database protocol for your web application. Be advised each database has its own method of secure lock down.
- ODBC Error Messaging: Turn off ODBC error messaging in your database server. Never display raw ODBC or other errors to the end user. See Removing Detailed Error Messages below, or consult your database server’s documentation, for more information.
- Uniform Error Codes: Ensure that you are not inadvertently supplying information to an attacker via the use of inconsistent or “conflicting” error messages. For instance, don’t reveal unintended information by utilizing error messages such as Access Denied, which will also let an attacker know that the file he seeks actually exists. Have consistent terminology for files and folders that do exist, do not exist, and which have read access denied.
- Informational Error Messages: Ensure that error messages do not reveal too much information. Complete or partial paths, variable and file names, row and column names in tables, and specific database errors should never be revealed to the end user. Remember, an attacker will gather as much information as possible, and then add pieces of seemingly innocuous information together to craft a method of attack.
- Proper Error Handling: Utilize generic error pages and error handling logic to inform end users of potential problems. Do not provide system information or other data that could be utilized by an attacker when orchestrating an attack.
- Stored Procedures: Consider using stored procedures. They require a very specific parameter format, which makes them less susceptible to SQL Injection attacks.
- Database Privileges: Utilize a least-privileges scheme for the database application. Ensure that user accounts only have the limited functionality that is actually required. All database mechanisms should deny access until it has been granted, not grant access until it has been denied.