Insecure Default Variable Initialization

Draft Variant

Structure: Simple

Description

This vulnerability occurs when software sets an internal variable to an insecure or unnecessarily weak default value during initialization, rather than using the most secure option available.

Extended Description

Insecure default initialization happens when a developer or framework assigns a starting value to a variable that is inherently vulnerable. Common examples include enabling debug modes, using weak cryptographic keys, granting excessive permissions, or turning security features off by default. This creates a hidden security gap because the system starts in a weakened state, often without the administrator or end-user being aware that they need to change a setting to be secure. To prevent this, developers should adopt a 'secure by default' design principle. This means the initial configuration should be the most restrictive and safest possible, requiring explicit action to loosen security, not the other way around. Always validate that security-critical variables like encryption settings, authentication flags, and privilege levels are initialized to their strongest values, and ensure documentation clearly warns against using insecure defaults.

Common Consequences 1

Scope: Integrity

Impact: Modify Application Data

An attacker could gain access to and modify sensitive data or system information.

Potential Mitigations 1

Phase: 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.

Demonstrative Examples 1

ID : DX-163

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

Code Example:

Bad

PHP

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

php

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:

Code Example:

Good

PHP

php

...*

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.

Observed Examples 1

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

Applicable Platforms

Languages:

PHP : SometimesNot Language-Specific : Undetermined

Modes of Introduction

Implementation

Related Weaknesses

ChildOf:

Initialization of a Resource with an Insecure Default (CWE-1188)

Taxonomy Mapping

PLOVER

Notes

MaintenanceThis overlaps other categories, probably should be split into separate items.