Cornucopia (C6)

This card is related to the handling of errors in a robust and consistent way (e.g. web server, application server, database server, JavaScript, other interpreters).

Scenario: Aaron’s Bypassing of Controls via Inadequate Error Handling

Imagine a situation where Aaron exploits weaknesses in an application’s error or exception handling mechanisms. This vulnerability arises from:

1. Absence or Inconsistency in Error Handling: The application lacks comprehensive error handling, or it is implemented inconsistently across different modules.
2. Non-Default Denial of Access on Error: Errors do not automatically lead to the termination of access or execution.
3. Dependence on External Error Handling: The application relies on other services or systems for its error management, creating gaps in control.
4. Information Leakage through Errors: Error messages reveal sensitive information that can be exploited.
5. Fallback to Insecure States: In the event of an error, the application reverts to a less secure state, like unencrypted communication or default credentials, allowing Aaron to bypass normal controls.

Example

Aaron targets a web application that has incomplete error handling routines. He induces errors in the application which, due to inadequate or inconsistent handling, expose sensitive information or system functionalities. Additionally, since errors do not default to denying access or terminating execution, Aaron uses these error states to bypass normal application controls. In some cases, the application relies on external systems to handle errors, and Aaron exploits the delay or miscommunication between these systems to gain unauthorized access or to revert the application to a less secure state.

Threat Modeling

STRIDE

The STRIDE category applicable here is Tampering.

Aaron is bypassing controls by exploiting weaknesses in error/exception handling. Errors are not handled consistently, allowing Aaron to access sensitive functions and do not default to denying access, so application logic can be bypassed. Reliance on other systems for error handling introduces exploitable gaps.

What can go wrong?

Such vulnerabilities in error handling can lead to unauthorized access, exposure of sensitive information, and potentially allow attackers to manipulate application behavior.

For more things that can go wrong, see the Common Attack Patterns related to this card in the table below.

What are we going to do about it?

Ensure all forms of error are handled robustly and consistently (e.g. web server, application server, database server, JavaScript, other interpreters). This encompasses:

1. Implement generic error messages and use custom error pages.
2. Develop and implement a comprehensive error and exception handling strategy that is consistently applied across the entire application.
3. Ensure that errors result in safe outcomes, such as terminating access or execution, to prevent exploitation. When exceptions occur, fail securely. Error handling logic associated with security controls should deny access by default.
4. Avoid relying solely on external systems for error handling; ensure that the application has robust internal mechanisms to deal with errors securely. The application should handle application errors and not rely on the server configuration.
5. Regularly review and test error handling routines to identify and address any weaknesses or inconsistencies.
6. Properly free allocated memory when error conditions occur.
7. Avoid fallback to insecure states in the event of an error, such as unencrypted communication or default credentials.

For detailed advice on how to mitigate threats related to the card, see the ASVS and OWASP Developer Guide requirements in the table below.