CWE-20: Improper Input Validation

Description:
The product receives input or data, but it does
        not validate or incorrectly validates that the input has the
        properties that are required to process the data safely and
        correctly.

Extended Description:
Input validation is a frequently-used technique
	   for checking potentially dangerous inputs in order to
	   ensure that the inputs are safe for processing within the
	   code, or when communicating with other components. 
	    Input can consist of: 
	    
	      raw data - strings, numbers, parameters, file contents, etc. 
	      metadata - information about the raw data, such as headers or size 
	    
	    Data can be simple or structured.  Structured data
	   can be composed of many nested layers, composed of
	   combinations of metadata and raw data, with other simple or
	   structured data. 
	    Many properties of raw data or metadata may need
	   to be validated upon entry into the code, such
	   as: 
	    
	      specified quantities such as size, length, frequency, price, rate, number of operations, time, etc. 
	      implied or derived quantities, such as the actual size of a file instead of a specified size 
	      indexes, offsets, or positions into more complex data struc

Affected languages: Not Language-Specific
Affected technologies: AI/ML
Parent weaknesses: CWE-707

Consequences:
  - Availability: DoS: Crash, Exit, or Restart
  - Confidentiality: Read Memory
  - Integrity: Modify Memory

Detection methods:
  - Automated Static Analysis: Some instances of improper input validation can be detected using automated static analysis. 
                   A static analysis tool might allow the user to specify which application-specific metho
  - Manual Static Analysis: When custom input validation is required, such as when enforcing business rules, manual analysis is necessary to ensure that the validation is properly implemented.
  - Fuzzing: Fuzzing techniques can be useful for detecting input validation errors. When unexpected inputs are provided to the software, the software should not crash or otherwise become unstable, and it should g
  - Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             

Mitigations:
  - [Architecture and Design] Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language.  This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representatio
  - [Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
  - [Architecture and Design] Understand all the potential areas where untrusted inputs can enter the product, including but not limited to: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, datab
  - [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. 
                   When pe

Demonstrative examples:
This example demonstrates a shopping interaction in which the user is free to specify the quantity of items to be purchased and a total is calculated.
The user has no control over the price variable, however the code does not prevent a negative value from being specified for quantity. If an attacker were to provide a negative value, then the user would have their account credited instead of debited.
... public static final double price = 20.00; int quantity = currentUser.getAttribute("quantity"); double total = price * quantity; chargeUser(total); ...

This example asks the user for a height and width of an m X n game board with a maximum dimension of 100 squares.
While this code checks to make sure the user cannot specify large, positive integers and consume too much memory, it does not check for negative values supplied by the user. As a result, an attacker can perform a resource consumption (CWE-400) attack against this program by specifying two, large negative values that will not overflow, resulting in a very large memory allocation (CWE-789) and possibly a system crash. Alternatively, an attacker can provide very large negative values which will cause an integer overflow (CWE-190) and unexpected behavior will follow depending on how the values are treated in the remainder of the program.
... #define MAX_DIM 100 ... 
               

Real-world examples:
  - CVE-2024-37032: Large language model (LLM) management tool does not
               validate the format of a digest value (CWE-1287) from a
               private, untrusted model registry, enabling relative
         
  - CVE-2022-45918: Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal u
  - CVE-2021-30860: Chain: improper input validation (CWE-20) leads to integer overflow (CWE-190) in mobile OS, as exploited in the wild per CISA KEV.
  - CVE-2021-30663: Chain: improper input validation (CWE-20) leads to integer overflow (CWE-190) in mobile OS, as exploited in the wild per CISA KEV.
  - CVE-2021-22205: Chain: backslash followed by a newline can bypass a validation step (CWE-20), leading to eval injection (CWE-95), as exploited in the wild per CISA KEV.