Secrets de l'historique de Git

Qu'est-ce que Secrets de l'historique de Git?

La suppression d'un identifiant codé en dur dans un nouveau commit ne le supprime pas. Git conserve chaque version de chaque fichier, de sorte que la valeur reste toujours dans la validation avant le nettoyage. Le code actuel semble propre, c’est pourquoi ces fuites survivent pendant des années. Vous trouverez le commit qui prétend avoir supprimé une clé API de production, lisez-le auparavant et rejouez-le avec l'API d'administration en direct. Ensuite, vous parcourrez l'historique avec git filter-repo, volontairement dans le mauvais ordre, et découvrirez pourquoi la rotation vient en premier.

Ce que vous apprendrez dans Secrets de l'historique de Git

• Reconnaissez que la suppression d'un secret codé en dur dans un nouveau commit ne le supprime pas : git conserve la valeur dans chaque commit précédent et dans le reflog, afin que toute personne qui clone le dépôt puisse le lire
• Suivez le chemin d'un attaquant depuis le clonage d'un dépôt public, jusqu'à la liste de l'historique des validations d'un fichier, jusqu'à l'affichage de la validation avant une suppression, jusqu'à la relecture d'une clé API en direct qui n'a jamais fait l'objet d'une rotation.
• Comprenez que la réécriture de l'historique ne peut pas rappeler un secret qui a déjà été cloné ou analysé, la rotation des informations d'identification est donc la seule étape qui invalide réellement la valeur divulguée.
• Donnez la priorité à la rotation des informations d'identification comme correctif principal et appliquez la réécriture de l'historique avec git filter-repo ou BFG et une mise à jour à distance forcée pour supprimer le secret de chaque validation en tant que nettoyage, et non en tant que correctif.
• Empêchez la récurrence en gardant les secrets hors de la source avec des variables d'environnement et en ajoutant un crochet d'analyse des secrets avant la validation afin qu'un identifiant soit bloqué avant qu'il n'entre dans l'historique du référentiel.

Secrets de l'historique de Git — Étapes de la formation

1. Évaluez la cible

   Aujourd'hui, Bob cible Larkfell, une société de développement de plates-formes qui effectue une grande partie de son travail à l'air libre. Il commence là où n'importe qui le ferait, sur le référentiel public, en évaluant ce que l'entreprise expédie avant de chercher un moyen d'y accéder. Un dépôt open source est un cadeau pour quelqu'un comme Bob : l'intégralité du projet, chaque fichier et chaque version de chaque fichier, le tout téléchargeable.

2. Cloner le dépôt

   Bob clone le référentiel sur sa propre machine afin de pouvoir effectuer des recherches dans l'ensemble du projet hors ligne, à son propre rythme. Le clone qu'il retire ne concerne pas seulement les fichiers actuels. C’est toute l’histoire, et c’est exactement ce qu’il recherche.

3. Vérifiez le code actuel

   Avant de creuser, Bob fait ce qu'un critique attentif ferait : il ouvre la configuration de production actuelle pour voir s'il reste quelque chose d'évident. C'est propre. La clé d'administrateur est lue à partir d'une variable d'environnement, et non écrite dans le fichier, donc rien n'est codé en dur ici. Un look décontracté s’arrêterait là.

4. Parcourez l'histoire

   Un dossier vierge à la HEAD ne dit rien du passé. La clé a disparu du code actuel, mais git a conservé toutes les versions antérieures de ce fichier. Bob le sait, il répertorie donc l'historique des validations de la configuration pour voir ce qu'elle contenait, pas seulement ce qu'elle contient maintenant.

5. La clé est toujours là

   Bob montre le commit qui a ajouté la configuration, celui juste avant le nettoyage. La validation de suppression a supprimé la ligne du code actuel, mais cette validation antérieure la contient toujours. La clé API de l'administrateur de production se trouve dans le fichier de comparaison en texte brut, exactement comme elle l'était avant que quelqu'un n'essaye de la supprimer.

6. La clé fonctionne toujours

   Une clé divulguée n'est qu'une théorie jusqu'à ce qu'elle ouvre quelque chose. Bob pointe la clé récupérée vers l'API d'administration de Larkfell, en la transportant dans un en-tête d'autorisation comme le ferait un vrai client. La clé n'a jamais subi de rotation après la validation de nettoyage, donc la valeur de cet ancien commit est toujours active.

7. La liste des clients est ouverte

   Le serveur a fait confiance à la clé et a répondu. Bob lit la liste interne des clients de Larkfell à partir d'une API publique, sans son propre compte.

8. Contrôle des connaissances

   Vous venez de voir un secret supprimé ouvrir toujours une API de production. Verrouillez pourquoi.

9. L'alerte débarque

   Vous possédez le dépôt backend de Larkfell. Du jour au lendemain, le service d'analyse secrète qui surveille vos référentiels publics a déclenché une alerte et vous l'a envoyée par e-mail. Le constat est sans appel : une clé API de production live est présente dans l’historique public des commits. Ce n'est pas dans le code actuel, mais le scanner a parcouru l'historique et l'a trouvé dans une validation antérieure.

10. Disparu de HEAD, vivant dans l'histoire

    Votre premier réflexe est de vérifier le code actuel, et la clé a réellement disparu de HEAD. Quelqu'un a déjà supprimé la ligne lors d'un commit ultérieur. Cela n’a pas aidé. Vous montrez vous-même le commit précédent et la clé en direct s'imprime immédiatement. Il survit dans chaque commit qui le contient encore, donc la suppression de la ligne de la dernière version a laissé les informations d'identification entièrement lisibles pour toute personne ayant cloné le dépôt.