The source code must have secure default options ensuring secure failures in the application (try, catch/except; default for switches).
The organization must ensure that its own systems and those of third parties are safe and fully comply with the functions for which they were implemented. For this, baselines must be implemented from the design and development phase, in order to avoid bad practices in the development cycles, e.g., the use of a conditional without a default option, which can cause unexpected behaviors in the system.
The system’s source code is safer when good programming practices are implemented from the development stage, ensuring the portability and maintenance of the application. If a system is difficult to maintain, vulnerabilities are more prone to arise.
Definition of baselines from design/architecture stages in order to guarantee the implementation of good programming practices in the development of the source code.
Quality code and source code vulnerability scanners: These are tools that perform code revision using lexical and syntactical analyzers. They process it, suggest improvements and highlight possible vulnerabilities in the development stage. Using this kind of tools during the development process helps improve performance, detect excessively complex logic and detect potential security issues.
Cause unexpected behaviors in the application.
Leak sensitive information from unexpected errors.
Layer: Application layer
Asset: Source code
Type of control: Recommendation
CAPEC-24: Filter Failure through Buffer Overflow. In this attack, the idea is to cause an active filter to fail by causing an oversized transaction. An attacker may try to feed overly long input strings to the program in an attempt to overwhelm the filter (by causing a buffer overflow) and hoping that the filter does not fail securely (i.e., the user input is let into the system unfiltered).
CAPEC-28: Fuzzing. In this attack pattern, the adversary leverages fuzzing to try to identify weaknesses in the system. Fuzzing is a software security and functionality testing method that feeds randomly constructed input to the system and looks for an indication that a failure in response to that input has occurred.
CWE-396: Declaration of Catch for Generic Exception. Catching overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
CWE-397: Declaration of Throws for Generic Exception. Throwing overly broad exceptions promotes complex error handling code that is more likely to contain security vulnerabilities.
CWE-478: Missing Default Case in Switch Statement. The code does not have a default case in a switch statement, which might lead to complex logical errors and resultant weaknesses.
CWE-544: Missing Standardized Error Handling Mechanism. The software does not use a standardized method for handling errors throughout the code, which might introduce inconsistent error handling and resultant weaknesses.
OWASP-ASVS v4.0.1 V4.1 General Access Control Design.(4.1.5) Verify that access controls fail securely including when an exception occurs.
OWASP-ASVS v4.0.1 V6.2 Algorithms.(6.2.1) Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable Padding Oracle attacks.
OWASP-ASVS v4.0.1 V7.4 Error Handling.(7.4.2) Verify that exception handling (or a functional equivalent) is used across the codebase to account for expected and unexpected error conditions.
OWASP-ASVS v4.0.1 V7.4 Error Handling.(7.4.3) Verify that a "last resort" error handler is defined which will catch all unhandled exceptions.
PCI DSS v3.2.1 - Requirement 6.5.5 Address common coding vulnerabilities in software-development processes such as improper error handling.