Exécuter une analyse statique (SAST) sur le code source à la recherche du motif non sécurisé dans le flux de données.
CWE-453 Variante Brouillon
Insecure Default Variable Initialization
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.
Définition
What is CWE-453?
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.
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.
Impact réel
Real-world CVEs caused by CWE-453
-
insecure default variable initialization in BIOS firmware for a hardware board allows DoS
Comment les attaquants l'exploitent
Parcours de l'attaquant étape par étape
- 1
This code attempts to login a user using credentials from a POST request:
- 2
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.
- 3
Here is a fixed version:
- 4
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.
Exemple de code vulnérable
Vulnerable PHP
This code attempts to login a user using credentials from a POST request:
```
// $user and $pass automatically set from POST request*
if (login_user($user,$pass)) {
```
$authorized = true;
}
```
...*
if ($authorized) {
```
generatePage();
} Exemple de code sécurisé
Secure PHP
Here is a fixed version:
$user = $_POST['user'];
$pass = $_POST['pass'];
$authorized = false;
if (login_user($user,$pass)) {
$authorized = true;
}
```
...* What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Liste de contrôle de prévention
How to prevent CWE-453
- 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.
Signaux de détection
How to detect CWE-453
Exécuter des tests de sécurité applicative dynamique (DAST) contre le point de terminaison en ligne.
Surveiller les journaux runtime pour détecter des traces d'exception inhabituelles, des entrées malformées ou des tentatives de contournement d'autorisation.
Revue de code : signaler tout nouveau code qui traite les entrées de cette surface sans utiliser les helpers du framework validés.
CWE-453
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Questions fréquentes Qu'est-ce que CWE-453 ?
Quelle est la gravité de CWE-453 ?
Quels langages ou plateformes sont affectés par CWE-453 ?
Comment puis-je prévenir CWE-453 ?
Comment Plexicus détecte et corrige CWE-453 ?
Où puis-je en savoir plus sur CWE-453 ?
Frequently asked questions
Qu'est-ce que CWE-453 ?
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.
Quelle est la gravité de CWE-453 ?
MITRE n'a pas publié de note de probabilité d'exploitation pour cette faiblesse. Traitez-la comme un impact moyen jusqu'à ce que votre modèle de menace prouve le contraire.
Quels langages ou plateformes sont affectés par CWE-453 ?
MITRE lists the following affected platforms: PHP.
Comment puis-je prévenir CWE-453 ?
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.
Comment Plexicus détecte et corrige CWE-453 ?
Le moteur SAST de Plexicus reconnaît la signature de flux de données de CWE-453 à chaque commit. Lorsqu'une correspondance est trouvée, notre agent Codex Remedium ouvre une PR de correction avec le code corrigé, les tests et un résumé d'une ligne pour le relecteur.
Où puis-je en savoir plus sur CWE-453 ?
MITRE publie la définition canonique à https://cwe.mitre.org/data/definitions/453.html. Vous pouvez également consulter la documentation OWASP et NIST pour des conseils adjacents.
Prêt à valider l'essentiel ?
Prêt à valider ce qui compte.
Plexicus est Proof-Driven AppSec : findings validés, compréhension contextuelle et remédiation relue — ancrée dans la preuve, scopée avec vous.