Analyse de la vulnérabilité de sauvegarde de base de données non authentifiée dans Craft CMS

Prérequis

Avant d'implémenter ces correctifs, vous aurez besoin de :

Accès au serveur requis :

• Accès SSH à votre serveur web
• Capacité de modifier les fichiers de configuration Apache ou Nginx
• Privilèges root ou sudo pour les modifications au niveau du système

Connaissances requises :

• Familiarité de base avec votre serveur web (Apache ou Nginx)
• Compréhension des chemins de fichiers et de la structure des répertoires
• Capacité de redémarrer les services du serveur web

Environnement Craft CMS :

• Installation Craft CMS 3.x, 4.x ou 5.x
• Accès à la structure de fichiers de votre projet
• Connaissance de l'emplacement de votre répertoire storage/ par rapport à votre webroot

Outils que vous utiliserez :

• Terminal/client SSH
• Éditeur de texte pour les fichiers de configuration
• cURL ou un navigateur web pour les tests

Comprendre le problème

Craft CMS stocke les sauvegardes de base de données, les journaux et les données d'exécution dans le répertoire storage/. Par défaut, la structure de projet de Craft garde ce dossier à l'extérieur du webroot public :

/var/www/project/
├── config/
├── storage/          ← Contient les sauvegardes, journaux, données d'exécution
│   └── backups/
├── templates/
├── vendor/
└── web/              ← Seul celui-ci devrait être accessible publiquement
    └── index.php

Le problème survient lorsque les déploiements placent storage/ à l'intérieur du webroot, ou lorsque les serveurs n'ont pas de règles bloquant l'accès direct. Un attaquant peut simplement demander :

curl https://votresite.com/storage/backups/craft_backup_2025-01-01-120000.sql

Et recevoir votre dump complet de base de données.

Ce n'est pas théorique. CVE-2025-54417 nécessite spécifiquement l'accès à /storage/backups comme partie de sa chaîne d'attaque. Les attaquants qui peuvent écrire des fichiers dans votre répertoire de sauvegarde et connaissent votre clé de sécurité peuvent exécuter du code arbitraire via le point de terminaison /updater/restore-db de Craft.

Implémentation étape par étape

Étape 1 : Identifier votre structure de répertoires actuelle

D'abord, déterminez si votre répertoire storage/ se trouve à l'intérieur ou à l'extérieur de votre webroot.

Connectez-vous à votre serveur et trouvez votre installation Craft :

# Trouvez votre installation Craft
find /var/www -name "craft" -type f 2>/dev/null

Vérifiez la relation entre storage/ et votre webroot :

# Depuis la racine de votre projet Craft
ls -la

Recherchez cette structure (sécuritaire) :

./config/
./storage/
./web/           ← La racine du document pointe uniquement ici

Ou cette structure (dangereuse) :

./web/
./web/config/
./web/storage/   ← Storage à l'intérieur du webroot

Étape 2 : Tester l'exposition actuelle

Avant d'effectuer des modifications, confirmez si vos sauvegardes sont actuellement accessibles.

Vérifiez si des sauvegardes existent :

ls -la storage/backups/

Testez l'accès HTTP direct depuis l'extérieur de votre serveur :

# Remplacez par votre domaine réel
curl -I https://votresite.com/storage/backups/

# Si vous connaissez un nom de fichier de sauvegarde
curl -I https://votresite.com/storage/backups/craft_backup_2025-01-01-120000.sql

Codes de réponse à surveiller :

• 200 OK — Vos sauvegardes sont exposées (critique)
• 403 Forbidden — Accès bloqué (bon)
• 404 Not Found — Soit bloqué, soit le chemin n'existe pas (vérifiez lequel)

Étape 3 : Déplacer storage à l'extérieur du webroot (méthode privilégiée)

Notre expérience montre que déplacer storage/ entièrement à l'extérieur du webroot élimine complètement cette classe de vulnérabilité. Pas de règles serveur à maintenir, pas de configuration à mal faire.

Si vous pouvez restructurer votre déploiement :

Créez la nouvelle structure de répertoires :

# Depuis la racine de votre projet (au-dessus de web/)
mkdir -p /var/www/project/storage

Déplacez le contenu existant de storage :

mv /var/www/project/web/storage/* /var/www/project/storage/
rmdir /var/www/project/web/storage

Mettez à jour votre fichier .env ou config/general.php pour pointer vers le nouvel emplacement :

// config/general.php
return [
    '*' => [
        // Définir explicitement le chemin de storage à l'extérieur du webroot
        'basePath' => dirname(__DIR__) . '/storage',
    ],
];

Définissez la bonne propriété :

chown -R www-data:www-data /var/www/project/storage
chmod -R 750 /var/www/project/storage

Étape 4 : Bloquer l'accès au niveau du serveur web (méthode alternative)

Si vous ne pouvez pas déplacer storage/ à l'extérieur du webroot (hébergement partagé, contraintes de plateforme), bloquez l'accès via la configuration du serveur.

Pour Apache :

Créez ou modifiez /var/www/project/web/storage/.htaccess :

# Refuser tout accès au répertoire storage
Require all denied

Ou ajoutez à la configuration de votre hôte virtuel Apache principal :

<VirtualHost *:443>
    ServerName votresite.com
    DocumentRoot /var/www/project/web
    
    # Bloquer l'accès au répertoire storage
    <Directory "/var/www/project/web/storage">
        Require all denied
    </Directory>
    
    # Protection supplémentaire : bloquer les extensions de fichiers de sauvegarde partout
    <FilesMatch "\.(sql|sql\.gz|sql\.zip|bak)$">
        Require all denied
    </FilesMatch>
</VirtualHost>

Redémarrez Apache :

sudo systemctl restart apache2

Pour Nginx :

Ajoutez à la configuration de votre bloc server :

server {
    listen 443 ssl;
    server_name votresite.com;
    root /var/www/project/web;
    
    # Bloquer complètement le répertoire storage
    location ^~ /storage/ {
        deny all;
        return 404;
    }
    
    # Bloquer les extensions de fichiers de sauvegarde partout
    location ~* \.(sql|bak)$ {
        deny all;
        return 404;
    }
    
    # Votre configuration Craft existante
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

Testez et rechargez Nginx :

sudo nginx -t
sudo systemctl reload nginx

Étape 5 : Définir les permissions de fichiers

Quelle que soit la méthode choisie, resserrez les permissions de fichiers sur le répertoire storage :

# Définir les permissions des répertoires
find /var/www/project/storage -type d -exec chmod 750 {} \;

# Définir les permissions des fichiers
find /var/www/project/storage -type f -exec chmod 640 {} \;

# Assurer la bonne propriété
chown -R www-data:www-data /var/www/project/storage

Ces permissions garantissent :

• Propriétaire (serveur web) : lecture, écriture, exécution sur les répertoires ; lecture, écriture sur les fichiers
• Groupe : lecture, exécution sur les répertoires ; lecture sur les fichiers
• Autres : aucun accès

Étape 6 : Configurer l'emplacement de stockage des sauvegardes

Pour une protection supplémentaire, configurez Craft pour écrire les sauvegardes dans un emplacement complètement à l'extérieur de votre projet web :

# Créer un répertoire de sauvegarde dédié
sudo mkdir -p /var/backups/craft
sudo chown www-data:www-data /var/backups/craft
sudo chmod 750 /var/backups/craft

Mettez à jour vos scripts de sauvegarde ou votre automatisation pour utiliser ce chemin. Si vous utilisez les commandes de sauvegarde intégrées de Craft :

./craft db/backup /var/backups/craft/

Erreurs courantes à éviter

Erreur 1 : Se fier uniquement au .htaccess sans vérifier qu'il fonctionne

Nous avons constaté que de nombreux environnements d'hébergement désactivent le traitement .htaccess pour des raisons de performance. Testez toujours que vos règles bloquent réellement l'accès plutôt que de supposer qu'elles le font.

Erreur 2 : Bloquer /storage/ mais pas /storage/backups/

Certaines configurations utilisent un matching de location qui ne s'applique pas aux sous-répertoires. Testez le chemin spécifique /storage/backups/, pas seulement le répertoire parent.

Erreur 3 : Utiliser des noms de fichiers de sauvegarde prévisibles sans contrôles d'accès

Le nommage par défaut des sauvegardes de Craft inclut des horodatages (craft_backup_2025-01-01-120000.sql). Ceux-ci sont faciles à deviner ou à énumérer. Même avec des contrôles d'accès, envisagez d'utiliser des noms de sauvegarde randomisés ou de stocker les sauvegardes avec des horodatages uniquement dans les métadonnées du nom de fichier.

Erreur 4 : Oublier l'indexation des répertoires

Si Options Indexes d'Apache est activé et que votre règle de blocage échoue, les attaquants peuvent parcourir /storage/backups/ et voir une liste de tous vos fichiers de sauvegarde. Désactivez l'indexation des répertoires :

<Directory "/var/www/project/web/storage">
    Options -Indexes
    Require all denied
</Directory>

Erreur 5 : Ne pas corriger les vulnérabilités Craft connexes

Bloquer l'accès aux sauvegardes réduit le risque, mais les CVE récents de Craft créent des chemins d'attaque supplémentaires. Un CVE-2025-32432 non corrigé donne aux attaquants l'exécution de code à distance, auquel cas ils peuvent accéder à n'importe quel fichier sur le serveur, peu importe les règles du serveur web.

Étapes de test et de vérification

Test 1 : Accès direct par URL

# Tester la racine de storage
curl -I https://votresite.com/storage/

# Tester le répertoire des sauvegardes
curl -I https://votresite.com/storage/backups/

# Tester un fichier de sauvegarde spécifique (utilisez un vrai nom de fichier si vous en connaissez un)
curl -I https://votresite.com/storage/backups/test.sql

Réponses attendues : 403 Forbidden ou 404 Not Found

Test 2 : Énumération des répertoires

# Vérifier si le listing des répertoires est désactivé
curl https://votresite.com/storage/backups/

Ne devrait pas retourner une liste de fichiers.

Test 3 : Vérification des permissions de fichiers

# Sur le serveur, vérifiez les permissions
ls -la /var/www/project/storage/
ls -la /var/www/project/storage/backups/

# Vérifier qu'il n'y a pas de permissions lisibles par tous (pas de 'r' dans le troisième groupe)
stat -c "%a %n" /var/www/project/storage/backups/*

Test 4 : Fonctionnalité Craft

Après avoir effectué les modifications, vérifiez que Craft fonctionne toujours correctement :

• Connectez-vous au panneau d'administration de Craft
• Naviguez vers Utilitaires → Rapport système
• Vérifiez s'il y a des avertissements de permissions de fichiers
• Exécutez une sauvegarde de test et confirmez qu'elle se termine avec succès

./craft db/backup

Test 5 : Scan de vulnérabilités externe

Utilisez la vérification serveur intégrée de Craft ou un scanner externe pour vérifier votre configuration :

# Le rapport système de Craft inclut des vérifications de sécurité
./craft utils/system-report

Correction des vulnérabilités connexes

Sécuriser vos sauvegardes est une couche de défense. Vous devez également corriger les CVE récents de Craft qui rendent les sauvegardes exposées plus dangereuses.

Mises à jour critiques requises :

• CVE-2025-32432 (Critique 10.0) — Corrigé dans : 3.9.15, 4.14.15, 5.6.17 — RCE non authentifié via les transformations d'images
• CVE-2025-54417 (Élevé) — Corrigé dans : 4.16.3, 5.8.4 — RCE via le point de terminaison de restauration de sauvegarde
• CVE-2025-23209 (Élevé 8.0) — Corrigé dans : 4.13.8, 5.5.8 — RCE avec clé de sécurité compromise
• CVE-2024-56145 (Critique 9.3) — Corrigé dans : 3.9.14, 4.13.2, 5.5.2 — RCE via la gestion argc/argv

Mettez à jour Craft CMS :

composer update craftcms/cms
./craft migrate/all
./craft project-config/apply

Après la mise à jour, effectuez une rotation de votre clé de sécurité si vous avez une raison de croire qu'elle a pu être exposée :

# Générer une nouvelle clé de sécurité
php -r "echo 'CRAFT_SECURITY_KEY=' . bin2hex(random_bytes(32)) . PHP_EOL;"

Mettez à jour votre fichier .env avec la nouvelle clé.

Conclusion

Protéger vos sauvegardes de base de données Craft CMS se résume à deux principes : garder les fichiers sensibles à l'extérieur du webroot, et bloquer l'accès à tout ce qui ne peut pas être déplacé. Les configurations serveur de ce guide adressent le risque d'exposition immédiat, mais elles fonctionnent mieux conjointement avec les correctifs Craft CMS actuels.

Travailler avec des équipes nous a appris que la sécurité des sauvegardes est souvent négligée parce qu'elle ne fait pas partie de l'application — c'est de l'infrastructure. Mais comme CVE-2025-54417 le démontre, les attaquants traitent /storage/backups comme un chemin direct vers l'exécution de code lorsqu'il est combiné avec d'autres vulnérabilités.

Si vous utilisez Craft CMS et n'avez pas audité l'exposition de votre répertoire storage, commencez par les tests curl de l'étape 2. Cette vérification de cinq minutes vous dit immédiatement si cet article s'applique à vous. Pour les équipes gérant plusieurs installations Craft ou cherchant à implémenter une gestion appropriée des sauvegardes dans le cadre d'une révision de sécurité plus large, nous pouvons vous aider à élaborer une approche qui couvre à la fois les correctifs immédiats et la surveillance continue.