CWE-1284: Improper Validation of Specified Quantity in… | Glexia

Causes

• 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.
• 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.
• The following code is a workflow job written using YAML. The code attempts to download pull request artifacts, unzip from the artifact called pr.zip and extract the value of the file NR into a variable "pr_number" that will be used later in another job. It attempts to create a github workflow environment variable, writing to $GITHUB_ENV. The environment variable value is retrieved from an external resource. The code does not neutralize the value of the file NR, e.g. by validating that NR only contains a number (CWE-1284). The NR file is attacker controlled because it originates from a pull request that produced pr.zip. The attacker could escape the existing pr_number and create a new variable using a "\n" (CWE-93) followed by any environment variable to be added such as: This would result in injecting and running javascript code (CWE-94) on the workflow runner with elevated privileges.
• The following PHP code could be from a shopping cart application. It allows users to apply a discount to an item. This code does not validate or restrict the discount percentage. An attacker could submit a discount value of 100, making the final price zero, or a value greater than 100, making the final price negative. Depending on how processPayment() handles zero or negative amounts, this could result in unauthorized free purchases or other payment logic flaws, such as getting money credited instead of paying. Notice that this new code still allows the attacker to choose the highest discount, which might be against the business logic of the application. It would be better to store the discounts in a database where they cannot be directly influenced by users, but that is outside the scope of CWE-1284.

Remediation

• 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 performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Detection

• Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Related CWEs

• CWE-20: Improper Input Validation
• CWE-20: Improper Input Validation
• CWE-789: Memory Allocation with Excessive Size Value
• CWE-606: Unchecked Input for Loop Condition

Related CVEs

Related CVE mappings appear after CVE records are cross-indexed.

ATT&CK Relevance

ATT&CK relevance is shown only when reviewed or responsibly inferred.