Trouver un mot de passe de base de données en dur dans un fichier de configuration

Chaque application web qui communique avec une base de données a besoin d'un nom d'utilisateur et d'un mot de passe pour ouvrir cette connexion. Dans les projets PHP, ces paramètres se trouvent presque toujours dans un petit fichier de configuration - généralement config.php - situé juste à côté de index.php à la racine web et inclus via require ou include. Le même schéma se retrouve partout ailleurs sous d'autres noms : settings.py pour Django, application.properties pour Spring, .env pour Node et Laravel, et docker-compose.yml pour les architectures conteneurisées.

Stocker l'identifiant dans un fichier livré avec l'application est pratique, mais c'est aussi la faiblesse que ce challenge met en évidence. Dès que vous disposez d'un accès en lecture à ce fichier, que ce soit un shell peu privilégié en tant qu'utilisateur du serveur web, une faille de path traversal, un dossier .git exposé, ou simplement un collègue qui clone le dépôt, le mot de passe de la base est visible en clair. Contrairement à une session volée qui expire, un identifiant de base de données divulgué accorde souvent un accès direct et persistant à toutes les données visibles par l'application.

Trouver le secret est avant tout une question de savoir où chercher. Depuis un shell, le plus rapide est de lister le répertoire web, repérer le fichier de config et le lire ; un grep récursif sur des mots-clés comme password, passwd ou db_pass fait ressortir la même valeur si le nom du fichier n'est pas évident. L'identifiant est stocké pour que l'application puisse l'envoyer à la base de données, il est donc conservé en texte clair, non hashé : c'est exactement pour cela que lire le fichier suffit.

• Chercher le mot de passe au mauvais endroit. L'identifiant ne se trouve pas dans /etc/passwd (ce fichier contient les comptes système, pas les secrets applicatifs) : il se trouve dans la propre configuration de l'application, à côté du contrôleur frontal.
• Ne vérifier que le fichier évident. Les identifiants sont souvent dupliqués dans un exemple de config, une sauvegarde comme config.php.bak, ou une ligne commentée laissée après des tests.
• Ignorer l'historique du contrôle de version. Un mot de passe supprimé du fichier actuel peut encore se trouver dans un commit antérieur, récupérable via le git log.
• Supposer qu'une valeur d'apparence aléatoire est hashée. Une chaîne de connexion à la base garde le mot de passe en texte clair pour que l'application puisse s'authentifier : ce n'est pas un hash à sens unique.

La correction durable consiste à garder les secrets hors des fichiers livrés avec le code, de sorte que la lecture de la racine web ne les révèle jamais :

• Charger l'identifiant de la base depuis une variable d'environnement à l'exécution plutôt que de le coder en dur dans config.php.
• Le stocker et le faire tourner dans un gestionnaire de secrets - un service de type vault ou le coffre de secrets de votre fournisseur cloud - plutôt que sur disque dans la racine web.
• Ajouter tout fichier contenant des secrets à .gitignore et ne commiter qu'un .env.example avec des valeurs d'exemple.
• Exécuter un outil de détection de secrets en CI pour intercepter un identifiant avant qu'il n'atteigne le dépôt distant.

Si un identifiant a déjà été commité ou exposé, considérez-le comme grillé et faites-le tourner immédiatement. Supprimer la ligne ne suffit pas, car l'ancienne valeur reste dans l'historique git et dans les sauvegardes éventuelles : changez le mot de passe de la base et mettez à jour l'application en production pour utiliser le nouveau secret.