Comment auditer la gestion des clés secrètes et des permissions dans Craft CMS pour prévenir les attaques RCE

Ce guide vous accompagne à travers un processus d'audit complet pour la gestion de vos clés secrètes Craft CMS, de l'identification de toutes les clés dans votre système à l'implémentation d'une surveillance qui détecte les problèmes avant qu'ils ne deviennent des violations. Vous apprendrez des techniques spécifiques pour sécuriser vos fichiers .env, définir des permissions appropriées et établir des pratiques de sécurité continues qui protègent vos sites.

Prérequis

Avant de commencer cet audit, assurez-vous d'avoir :

• Accès au serveur avec des privilèges de ligne de commande
• Accès administrateur à votre installation Craft CMS
• Familiarité de base avec les variables d'environnement et les permissions de fichiers
• Accès à votre système de contrôle de version pour scanner l'historique
• Sauvegarde de votre configuration actuelle avant d'effectuer des changements

Outils requis :

• Accès à la ligne de commande (SSH ou terminal local)
• Éditeur de texte pour les fichiers de configuration
• Accès Git (si vous utilisez un contrôle de version)
• TruffleHog ou un outil similaire de détection de secrets

Temps requis : 2-4 heures pour un audit complet

Étape 1 : Localiser et inventorier toutes les clés secrètes

Commencez par créer un inventaire complet de chaque secret dans votre installation Craft CMS. Beaucoup de violations de sécurité se produisent parce que les équipes manquent des clés stockées dans des endroits inattendus.

Emplacements principaux des secrets

Vérifiez ces emplacements par ordre de priorité :

1. Fichiers d'environnement (.env)

# Naviguez vers le répertoire racine de votre site Craft CMS
cd /chemin/vers/votre/site/craft
ls -la .env*

Recherchez des fichiers comme .env, .env.local, .env.production, .env.staging.

2. Fichiers de configuration

# Vérifiez le répertoire de configuration principal
ls -la config/
# Recherchez des secrets codés en dur (cela devrait retourner des résultats vides)
grep -r "SECURITY_KEY\|DB_PASSWORD\|API_KEY" config/

3. Configuration des extensions

# Vérifiez les variables d'environnement spécifiques aux extensions
grep -r "getenv\|$_ENV" config/

Créez votre inventaire des secrets

Documentez chaque secret que vous trouvez :

INVENTAIRE DES SECRETS:
- SECURITY_KEY: Emplacement, Dernière rotation, Objectif
- DB_PASSWORD: Emplacement, Dernière rotation, Objectif  
- MAILGUN_API_KEY: Emplacement, Dernière rotation, Objectif
- STRIPE_SECRET_KEY: Emplacement, Dernière rotation, Objectif

Nous avons constaté que les équipes découvrent souvent 3-5 secrets de plus qu'elles ne s'y attendaient initialement lors de ce processus d'inventaire.

Étape 2 : Vérifier les modèles de stockage sécurisé

Maintenant, auditez comment chaque secret est stocké. Chaque secret devrait suivre le même modèle sécurisé.

Modèle de stockage correct

Bon : Secrets dans le fichier .env

# fichier .env (à l'extérieur de la racine web)
SECURITY_KEY=base64:8hJ3k9mL2nP5qR6sT7uV8wX9yZ0aB1cD2eF3g
DB_PASSWORD=votre_mot_de_passe_base_de_donnees_securise
MAILGUN_API_KEY=key-1234567890abcdef

Bon : La configuration référence l'environnement

 getenv('SECURITY_KEY'),
    'devMode' => getenv('DEV_MODE') === 'true',
];

Modèles de stockage dangereux

Mauvais : Secrets codés en dur

 'base64:8hJ3k9mL2nP5qR6sT7uV8wX9yZ0aB1cD2eF3g', // Exposé !
];

Mauvais : Secrets dans les gabarits

{# templates/contact.twig - NE JAMAIS FAIRE CELA #}

Corriger les problèmes de stockage

Si vous trouvez des secrets codés en dur, déplacez-les immédiatement :

1. Ajouter au fichier .env :

# Ajoutez le secret à votre fichier .env
NEW_SECRET_KEY=la_valeur_codee_en_dur_que_vous_avez_trouvee

2. Mettre à jour la configuration :

 getenv('NEW_SECRET_KEY'),
];

3. Testez le changement avant de continuer.

Étape 3 : Auditer les permissions de fichiers et le contrôle d'accès

Des permissions de fichiers appropriées empêchent l'accès non autorisé à vos secrets, même si quelqu'un obtient un accès au serveur.

Vérifier les permissions actuelles

# Vérifiez les permissions du fichier .env
ls -la .env
# Devrait afficher quelque chose comme : -rw------- 1 www-data www-data 245 Aug  9 10:30 .env

# Vérifiez les permissions du répertoire config
ls -la config/
# Les fichiers devraient être lisibles uniquement par l'utilisateur du serveur web

Définir les permissions correctes

Pour les fichiers .env :

# Définissez des permissions restrictives (lecture/écriture propriétaire seulement)
chmod 600 .env
# Assurez-vous que le serveur web possède le fichier
chown www-data:www-data .env

Pour les fichiers de configuration :

# Les fichiers de configuration peuvent être lisibles par le groupe
chmod 640 config/*.php
chown www-data:www-data config/*.php

Vérifier les restrictions d'accès web

Testez que vos secrets ne sont pas accessibles via des requêtes web :

# Testez l'accès au fichier .env (devrait échouer)
curl -I https://votre-site.com/.env
# Résultat attendu : 404 Not Found ou 403 Forbidden

# Testez l'accès aux fichiers de configuration (devrait échouer)  
curl -I https://votre-site.com/config/general.php
# Résultat attendu : 404 Not Found ou 403 Forbidden

Si ces fichiers sont accessibles, configurez votre serveur web pour les bloquer :

Apache (.htaccess) :

# Bloquez l'accès aux fichiers sensibles

    Require all denied


    
        Require all denied
        Require file config/general.php
    

Nginx :

# Bloquez l'accès aux fichiers sensibles
location ~ /\.env {
    deny all;
    return 404;
}
location ~* ^/config/.*\.php$ {
    deny all;
    return 404;
}

Étape 4 : Rechercher les secrets divulgués dans le contrôle de version

L'une des erreurs de sécurité les plus courantes est de soumettre accidentellement des secrets au contrôle de version. Même si vous les supprimez plus tard, ils restent dans votre historique Git.

Installer et exécuter TruffleHog

# Installez TruffleHog
pip install truffleHog

# Scannez votre dépôt pour des secrets
trufflehog --regex --entropy=False .

Vérification manuelle de l'historique Git

# Recherchez dans l'historique Git des secrets potentiels
git log --all -p -S "SECURITY_KEY" 
git log --all -p -S "password"
git log --all -p -S "api_key"

Nettoyer l'historique compromis

Si vous trouvez des secrets dans votre historique Git :

Option 1 : BFG Repo-Cleaner (recommandé)

# Téléchargez BFG depuis https://rtyley.github.io/bfg-repo-cleaner/
java -jar bfg.jar --delete-files .env
java -jar bfg.jar --replace-text passwords.txt

Option 2 : Git filter-branch

# Supprimez un fichier spécifique de l'historique
git filter-branch --force --index-filter \
'git rm --cached --ignore-unmatch .env' \
--prune-empty --tag-name-filter cat -- --all

Critique : Après avoir nettoyé l'historique Git, effectuez immédiatement la rotation de tous les secrets exposés.

Étape 5 : Tester l'accès aux secrets et la fonctionnalité

Vérifiez que vos changements de sécurité n'ont pas cassé la fonctionnalité tout en confirmant que les secrets sont correctement protégés.

Tests fonctionnels

1. Testez que Craft CMS se charge correctement :

# Vérifiez si le site se charge sans erreurs
curl -I https://votre-site.com/admin
# Devrait retourner 200 OK ou rediriger vers la page de connexion

2. Testez la connectivité de la base de données :

# Depuis le répertoire Craft CMS
php craft help
# Devrait se connecter à la base de données sans erreurs

3. Testez la fonctionnalité de courriel :

// Créez un contrôleur de test ou utilisez la console de Craft
php craft mailer/test [email protected]

Tests de validation de sécurité

1. Vérifiez que les secrets ne sont pas accessibles via le web :

# Tous ces tests devraient échouer avec 404 ou 403
curl https://votre-site.com/.env
curl https://votre-site.com/.env.local
curl https://votre-site.com/config/general.php

2. Vérifiez la divulgation d'informations :

# Recherchez des messages d'erreur qui pourraient exposer des chemins ou configurations
curl https://votre-site.com/page-inexistante
# Devrait afficher un 404 générique, pas des chemins système

3. Validez les permissions de fichiers :

# Confirmez que les permissions restrictives sont maintenues
ls -la .env config/

Étape 6 : Implémenter une surveillance continue des secrets

Mettez en place des systèmes pour détecter une future exposition de secrets avant que cela ne devienne un problème.

Analyse automatisée des secrets

Intégration GitHub :

# .github/workflows/secret-scan.yml
name: Secret Scan
on: [push, pull_request]
jobs:
  secret-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Run TruffleHog
        run: |
          pip install trufflehog
          trufflehog --regex --entropy=False .

Hook de pré-soumission local :

#!/bin/sh
# .git/hooks/pre-commit
if git diff --cached --name-only | grep -E "\.(env|config)" > /dev/null; then
    echo "Avertissement : Fichiers d'environnement ou de configuration dans la soumission"
    echo "Analyse des secrets en cours..."
    trufflehog --regex --entropy=False --branch HEAD
    if [ $? -ne 0 ]; then
        echo "Secret détecté ! Soumission bloquée."
        exit 1
    fi
fi

Surveillance des journaux

Mettez en place une surveillance pour les tentatives d'accès suspectes :

# Surveillez les journaux du serveur web pour les tentatives d'accès .env
tail -f /var/log/nginx/access.log | grep "\.env"
# Configurez des alertes pour toute correspondance

Erreurs communes à éviter

Basé sur des audits de sécurité à travers des centaines de sites Craft CMS, voici les erreurs les plus fréquentes qui mènent à des secrets compromis :

Erreur 1 : Gestion inconsistante de l'environnement

Problème : Différents secrets stockés de différentes façons

// Inconsistant - certains depuis l'env, d'autres codés en dur
return [
    'securityKey' => getenv('SECURITY_KEY'), // Bon
    'license' => 'ABCD-1234-EFGH-5678',      // Mauvais - codé en dur
];

Solution : Établir et suivre un modèle de façon cohérente

return [
    'securityKey' => getenv('SECURITY_KEY'),
    'license' => getenv('CRAFT_LICENSE_KEY'),
];

Erreur 2 : Permissions de fichiers faibles

Problème : Fichiers secrets lisibles par tous

-rw-rw-rw- 1 www-data www-data 245 Aug  9 10:30 .env  # Trop ouvert !

Solution : Restreindre les permissions correctement

chmod 600 .env  # Lecture/écriture propriétaire seulement

Erreur 3 : Secrets dans les messages d'erreur

Problème : Mode débogage exposant les variables d'environnement

// config/general.php
return [
    'devMode' => true, // Dangereux en production
];

Solution : Paramètres de débogage spécifiques à l'environnement

return [
    'devMode' => getenv('DEV_MODE') === 'true',
];

Erreur 4 : Oublier les secrets d'extensions

Problème : Sécuriser les secrets principaux mais manquer les clés API d'extensions

# Secrets d'extensions manquants
SECURITY_KEY=base64:abc123
DB_PASSWORD=secret
# Où sont STRIPE_KEY, MAILGUN_API_KEY, etc?

Solution : Auditer toutes les extensions pour les exigences de secrets

grep -r "getenv\|config.*key" vendor/

Étapes de vérification

Complétez ces vérifications finales pour confirmer que votre audit a été réussi :

Liste de vérification sécuritaire

# 1. Tous les secrets dans les fichiers .env seulement
grep -r "key.*=" config/ | grep -v getenv
# Devrait retourner vide

# 2. Permissions de fichiers appropriées  
ls -la .env
# Devrait afficher les permissions 600

# 3. Aucun accès web aux fichiers sensibles
curl -I https://votre-site.com/.env
# Devrait retourner 404 ou 403

# 4. Historique Git propre
git log --oneline -p -S "password" --all
# Devrait retourner vide ou des résultats attendus

# 5. Les tests fonctionnels passent
php craft help
# Devrait fonctionner sans erreurs de base de données

Vérification de documentation

Assurez-vous d'avoir documenté :

• Emplacement de toutes les clés secrètes
• Dates de dernière rotation
• Membres d'équipe responsables
• Procédures de rotation d'urgence
• Configuration de surveillance et d'alertes

Conclusion et prochaines étapes

La sécurité des clés secrètes forme la fondation de votre posture de sécurité Craft CMS. En complétant cet audit, vous avez identifié tous les secrets dans votre système, sécurisé leur stockage avec des permissions appropriées, éliminé l'exposition historique dans le contrôle de version et établi une surveillance pour une protection future.

Notre expérience montre que les équipes qui suivent ce processus d'audit découvrent en moyenne 3-4 problèmes de sécurité dans leur configuration existante, les permissions de fichiers et l'exposition du contrôle de version étant les problèmes les plus courants.

Prochaines étapes immédiates :

• Effectuer la rotation de tous les secrets qui ont été trouvés exposés ou stockés de manière inappropriée
• Mettre à jour Craft CMS vers la dernière version pour corriger les vulnérabilités connues
• Planifier des audits réguliers trimestriellement ou après tout changement de configuration majeur
• Former votre équipe sur ces pratiques sécurisées pour le développement futur

Gérer les clés secrètes à travers plusieurs sites Craft CMS nécessite une coordination soigneuse des calendriers de rotation, des audits de permissions et des systèmes de surveillance. Si vous cherchez à établir des pratiques de sécurité cohérentes à travers vos propriétés web ou avez besoin d'aide pour implémenter une gestion automatisée des secrets, nous pouvons vous aider à concevoir une approche qui évolue avec le flux de travail de votre équipe tout en maintenant les standards de sécurité que vos projets exigent.