CWE-453: Insecure Default Variable Initialization

Description

The product, by default, initializes an internal variable with an insecure or less secure value than is possible.

Potential Impact

Integrity

Modify Application Data

Demonstrative Examples

This code attempts to login a user using credentials from a POST request:

Bad

// $user and $pass automatically set from POST request
                     if (login_user($user,$pass)) {$authorized = true;}
                     ...
                     
                     if ($authorized) {generatePage();}

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:

Good

$user = $_POST['user'];$pass = $_POST['pass'];$authorized = false;if (login_user($user,$pass)) {$authorized = true;}
                     ...

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.

Mitigations & Prevention

System Configuration

Disable or change default settings when they can be used to abuse the system. Since those default settings are shipped with the product they are likely to be known by a potential attacker who is familiar with the product. For instance, default credentials should be changed or the associated accounts should be disabled.

Detection Methods

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 sea

Real-World CVE Examples

CVE ID	Description
CVE-2022-36349	insecure default variable initialization in BIOS firmware for a hardware board allows DoS

Taxonomy Mappings

PLOVER: — Insecure default variable initialization

Frequently Asked Questions

What is CWE-453?

CWE-453 (Insecure Default Variable Initialization) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Variant-level weakness. The product, by default, initializes an internal variable with an insecure or less secure value than is possible.

How can CWE-453 be exploited?

Attackers can exploit CWE-453 (Insecure Default Variable Initialization) to modify application data. This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-453?

Key mitigations include: Disable or change default settings when they can be used to abuse the system. Since those default settings are shipped with the product they are likely to be known by a potential attacker who is famil

What is the severity of CWE-453?

CWE-453 is classified as a Variant-level weakness (Low-Medium abstraction). It has been observed in 1 real-world CVEs.