Segreti nella storia di Git

Cos’è Segreti nella storia di Git?

L'eliminazione di una credenziale hardcoded in un nuovo commit non la rimuove. Git conserva ogni versione di ogni file, quindi il valore si trova ancora nel commit prima della pulizia. Il codice attuale sembra pulito, motivo per cui queste fughe di notizie sopravvivono per anni. Troverai il commit che afferma di aver rimosso una chiave API di produzione, lo leggi prima dal commit e lo riproduci rispetto all'API di amministrazione live. Quindi cancellerai la cronologia con git filter-repo, volutamente nell'ordine sbagliato, e imparerai perché la rotazione viene prima.

Cosa imparerai in Segreti nella storia di Git

• Riconosci che l'eliminazione di un segreto hardcoded in un nuovo commit non lo rimuove: git conserva il valore in ogni commit precedente e nel reflog, quindi chiunque cloni il repository può leggerlo
• Segui il percorso di un utente malintenzionato dalla clonazione di un repository pubblico, all'elenco della cronologia dei commit di un file, alla visualizzazione del commit prima di una rimozione, alla riproduzione di una chiave API live che non è mai stata ruotata
• Tieni presente che la riscrittura della cronologia non può richiamare un segreto che è già stato clonato o scansionato, quindi ruotare la credenziale è l'unico passaggio che invalida effettivamente il valore trapelato
• Dai priorità alla rotazione delle credenziali come correzione principale e applica la riscrittura della cronologia con git filter-repo o BFG e un aggiornamento remoto forzato per rimuovere il segreto da ogni commit come pulizia, non come correzione
• Previeni la ricorrenza mantenendo i segreti fuori dall'origine con variabili di ambiente e aggiungendo un hook di scansione dei segreti pre-commit in modo che una credenziale venga bloccata prima che entri nella cronologia del repository

Segreti nella storia di Git — Fasi della formazione

1. Dimensionare il bersaglio

   Oggi Bob si rivolge a Larkfell, una società di piattaforme di sviluppo che svolge gran parte del suo lavoro all'aperto. Inizia da dove chiunque farebbe, nell'archivio pubblico, valutando ciò che la compagnia spedisce prima di cercare un modo per entrarci. Un repository open source è un regalo per qualcuno come Bob: l'intero progetto, ogni file e ogni versione di ogni file, tutti scaricabili.

2. Clona il repository

   Bob clona il repository sul proprio computer in modo da poter effettuare ricerche nell'intero progetto offline, al proprio ritmo. Il clone che tira giù non sono solo i file attuali. È l'intera storia, che è esattamente ciò che sta cercando.

3. Controlla il codice attuale

   Prima di scavare, Bob fa quello che farebbe un revisore attento: apre la configurazione di produzione corrente per vedere se è rimasto qualcosa di ovvio. È pulito. La chiave amministratore viene letta da una variabile di ambiente, non scritta nel file, quindi qui non è codificato nulla. Un look casual si fermerebbe proprio lì.

4. Percorri la storia

   Un dossier pulito presso HEAD non dice nulla del passato. La chiave è scomparsa dal codice corrente, ma git ha conservato ogni versione precedente di quel file. Bob lo sa, quindi elenca la cronologia dei commit della configurazione per vedere cosa conteneva, non solo cosa contiene ora.

5. La chiave è ancora lì

   Bob mostra il commit che ha aggiunto la configurazione, quello subito prima della pulizia. Il commit di rimozione ha eliminato la riga dal codice corrente, ma questo commit precedente la conserva ancora. La chiave API dell'amministratore di produzione si trova nel diff in testo normale, esattamente come era prima che qualcuno tentasse di estrarla.

6. La chiave funziona ancora

   Una chiave trapelata è solo una teoria finché non apre qualcosa. Bob indirizza la chiave recuperata all'API di amministrazione di Larkfell, trasportandola in un'intestazione di autorizzazione come farebbe un vero client. La chiave non è mai stata ruotata dopo il commit di pulizia, quindi il valore del vecchio commit è ancora attivo.

7. L'elenco dei clienti è aperto

   Il server si è fidato della chiave e ha risposto. Bob sta leggendo l'elenco dei clienti interni di Larkfell da un'API pubblica, senza alcun account proprio.

8. Verifica della conoscenza

   Hai appena visto un segreto eliminato aprire ancora un'API di produzione. Blocca il perché.

9. Arriva l'allerta

   Possiedi il repository backend di Larkfell. Durante la notte, il servizio di scansione segreta che controlla i tuoi repository pubblici ha lanciato un avviso e te lo ha inviato via email. La scoperta è schietta: una chiave API di produzione live è presente nella cronologia dei commit pubblici. Non è nel codice corrente, ma lo scanner ha esaminato la cronologia e l'ha trovato in un commit precedente.

10. Fuori dalla HEAD, vivo nella storia

    Il tuo primo istinto è controllare il codice corrente e la chiave è davvero sparita da HEAD. Qualcuno ha già eliminato la riga in un commit successivo. Questo non ha aiutato. Mostri tu stesso il commit precedente e la chiave live viene stampata di nuovo. Sopravvive in ogni commit che ancora lo contiene, quindi l'eliminazione della riga dall'ultima versione ha lasciato le credenziali completamente leggibili per chiunque abbia clonato il repository.