CWE-913: Improper Control of Dynamically-Managed Code Resources

Causes

• This example attempts to write user messages to a message file and allow users to view them. While the programmer intends for the MessageFile to only include data, an attacker can provide a message such as:,which will decode to the following:,The programmer thought they were just including the contents of a regular data file, but PHP parsed it and executed the code. Now, this code is executed any time people view messages.,Notice that XSS (CWE-79) is also possible in this situation.
• A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection: A programmer might refactor this code to use reflection as follows:,[object Object],One way to address this access control problem is to make the Worker object responsible for performing the access control check. An example of the re-refactored code follows:,Although this is an improvement, it encourages a decentralized approach to access control, which makes it easier for programmers to make access control mistakes.,This code also highlights another security problem with using reflection to build a command dispatcher. An attacker can invoke the default constructor for any kind of object. In fact, the attacker is not even constrained to objects that implement the Worker interface; the default constructor for any object in the system can be invoked. If the object does not implement the Worker interface, a ClassCastException will be thrown before the assignment to ao, but if the constructor performs operations that work in the attacker's favor, the damage will already have been done. Although this scenario is relatively benign in simple products, in larger products where complexity grows exponentially, it is not unreasonable that an attacker could find a constructor to leverage as part of an attack.

Remediation

• Implementation: For any externally-influenced input, check the input against an allowlist of acceptable values.
• Implementation,Architecture and Design: Refactor the code so that it does not need to be dynamically managed.

Detection

• Fuzzing: Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Related CWEs

• CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
• CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
• CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
• CWE-502: Deserialization of Untrusted Data
• CWE-502: Deserialization of Untrusted Data
• CWE-664: Improper Control of a Resource Through its Lifetime
• CWE-914: Improper Control of Dynamically-Identified Variables
• CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
• CWE-94: Improper Control of Generation of Code ('Code Injection')

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.