CWE-454: External Initialization of Trusted Variables or Data Stores
Official CWE-454 CWE context with Glexia analysis, remediation guidance, related CVEs, and ATT&CK context.
Glexia's Take
CWE-454: External Initialization of Trusted Variables or Data Stores
External Initialization of Trusted Variables or Data Stores represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Integrity: Modify Application Data: An attacker could gain access to and modify sensitive data or system information.
Developer Pattern
CWE-454 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Confidence
high confidence from CWE-454, 4.20.
Official CWE Definition
CWE-454: External Initialization of Trusted Variables or Data Stores
The product initializes critical internal variables or data stores using inputs that can be modified by untrusted actors.
A product 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.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- 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)
Remediation
- Implementation: A product system should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking (e.g. input validation) is performed when relying on input from outside a trust boundary.
- Architecture and Design: Avoid any external control of variables. If necessary, restrict the variables that can be modified using an allowlist, and use a different namespace or naming convention if possible.
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.)
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.