External Initialization of Trusted Variables or Data Stores
The software initializes critical internal variables or data stores using inputs that can be modified by untrusted actors.
A software system should be reluctant to trust variables that have been initialized outside of its trust boundary, especially if they are initialized by users. The variables may have been initialized incorrectly. If an attacker can initialize the variable, then they can influence what the vulnerable system will do.
The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.
Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.
In the Java example below, a system property controls the debug level of the application.
If an attacker is able to modify the system property, then it may be possible to coax the application into divulging sensitive information by virtue of the fact that additional debug information is printed/exposed as the debug level increases.
This code checks the HTTP POST request for a debug switch, and enables a debug mode if the switch is set.
Any user can activate the debug mode, gaining administrator privileges. An attacker may also use the information printed by the phpinfo() function to further exploit the system. .
This example also exhibits Information Exposure Through Debug Information (CWE-215)
This category identifies Software Fault Patterns (SFPs) within the Tainted Input to Variable cluster (SFP25).
Weaknesses in this category occur in behaviors that are used for initialization and breakdown.
This view (slice) covers all the elements in CWE.
This view contains a selection of weaknesses that represent the variety of weaknesses that are captured in CWE, at a level of abstraction that is likely to be useful t...
This view (slice) lists weaknesses that can be introduced during implementation.