Insecure Default Variable Initialization
The software, by default, initializes an internal variable with an insecure or less secure value than is possible.
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.
This code attempts to login a user using credentials from a POST request:
Because the $authorized variable is never initialized, PHP will automatically set $authorized to any value included in the POST request if register_globals is enabled. An attacker can send a POST request with an unexpected third value 'authorized' set to 'true' and gain authorized status without supplying valid credentials.
Here is a fixed version:
This code avoids the issue by initializing the $authorized variable to false and explicitly retrieving the login credentials from the $_POST variable. Regardless, register_globals should never be enabled and is disabled by default in current versions of PHP.
This category identifies Software Fault Patterns (SFPs) within the Other Exposures cluster.
This view (slice) covers all the elements in CWE.
CWE entries in this view have maintenance notes. Maintenance notes are an indicator that an entry might change significantly in future versions. This view was created...
CWE identifiers in this view are weaknesses that do not have associated Software Fault Patterns (SFPs), as covered by the CWE-888 view. As such, they represent gaps in...