File segreti depositati

Cos’è File segreti depositati?

L'hardcoding di un segreto è un problema; commetterne un intero file è peggio. Un repository senza .gitignore tiene traccia dei file .env, delle chiavi private e del JSON dell'account di servizio dal primo commit e ogni clone porta con sé una copia di quella cronologia. Clonerai un repository pubblico, leggerai il suo .env impegnato e raggiungerai la messa in scena live. Quindi annullerai la traccia dei file con git rm --cached, revocherai e riemetterai la chiave API trapelata, aggiungerai un .gitignore e eseguirai il commit di una configurazione pre-commit che blocca i nomi di file segreti una volta che ciascuno sviluppatore lo installa.

Cosa imparerai in File segreti depositati

• Riconoscere che un .gitignore mancante o incompleto consente di eseguire il commit e il monitoraggio di un intero file segreto, un .env, una chiave privata o un JSON dell'account di servizio dal primo commit
• Comprendere perché ogni clone di un repository pubblico trasporta una copia di un file segreto tracciato, quindi l'esposizione non può essere annullata eliminando il file in un secondo momento
• Distinguere il commit di un FILE segreto sotto controllo di versione dall'hardcoding di un letterale segreto all'interno del codice sorgente e sapere che entrambi devono essere tenuti fuori dal repository
• Applica la pulizia: rimuovi i file dal tracciamento con git rm --cached e ruota le chiavi esposte, trattando qualsiasi segreto inviato come compromesso
• Previeni la ricorrenza con un .gitignore che copre i file segreti più un hook di pre-commit che blocca i nomi di file segreti conosciuti prima che vengano sottoposti a commit, installato in ogni clone e supportato dalla protezione push lato server

File segreti depositati — Fasi della formazione

1. Dimensionare il bersaglio

   Oggi Bob prende di mira Tavonn, una startup di integrazione dei pagamenti che distribuisce parte del suo codice allo scoperto. Inizia dall'archivio pubblico, valutando ciò che l'azienda gestisce prima di cercare un modo per entrarvi. Un repository pubblico è un regalo per qualcuno come Bob: l'intero progetto, ogni file, scaricabile in un unico comando.

2. Clona il repository

   Bob clona il repository sul suo computer in modo da poter leggere ogni file di cui tiene traccia, offline e al proprio ritmo. Qualunque sia la traccia del repository, arriva con il clone. Se mai è stato commesso un file segreto, è nella copia che ha appena estratto.

3. Elenca i file tracciati

   Bob elenca tutto ciò che viene tracciato dal repository. Non sta guardando cosa c'è sul disco, sta chiedendo a git quali file sono effettivamente sotto il controllo della versione, perché quelli sono quelli che ogni clone trasporta.

4. Leggi il file segreto

   Bob apre il file dell'ambiente committato. Questa è la differenza tra questa fuga di notizie e una singola chiave codificata: non è un valore incollato in una riga di codice, è un intero file di segreti sotto il controllo della versione. Tutto ciò di cui il servizio ha bisogno per funzionare è qui, in testo semplice.

5. Raggiungere l'ambiente di staging

   Una chiave trapelata è solo una teoria finché non apre qualcosa. Bob ha già tutto ciò di cui ha bisogno dal clone: l' .env committato gli ha fornito l'URL di base dell'API in PUBLIC_API_URL e una chiave live, e i percorsi che ha clonato in src/routes/payments.js definiscono il feed di pagamento in /v1/transactions . Assembla la richiesta e porta la chiave in un'intestazione Authorization come farebbe un vero cliente. Gli endpoint non sono mai stati il segreto; si siedono nella fonte pubblica. La chiave era e il file committato gliene ha consegnato uno, quindi il server non ha motivo di rifiutare la richiesta.

6. I dati di pagamento sono aperti

   Il server si è fidato della chiave e ha risposto. Bob sta leggendo i registri dei pagamenti temporanei di Tavonn dall'esterno dell'azienda, senza alcun resoconto proprio.

7. Verifica della conoscenza

8. Arriva l'allerta

   Possiedi il repository dei servizi di pagamento di Tavonn. Durante la notte, lo scanner segreto del team di sicurezza ha contrassegnato l'archivio pubblico e ti ha inviato un'e-mail. La scoperta è schietta: un .env committato con chiavi live si trova nel repository pubblico e non c'è nessun .gitignore che tenga fuori file simili.

9. Tracciato, senza .gitignore

   La tua prima mossa è vederlo di persona. Elenca ciò che git sta monitorando nel repository, ed eccolo lì: .env e la chiave dell'account di servizio sono sotto il controllo della versione e nessun .gitignore è nell'elenco. Un file presente su disco è una cosa; viene eseguito il commit di un file che Git sta monitorando, nella cronologia e in ogni clone.

10. Scopri i file segreti

    Impedisci a git di tracciare i file segreti con git rm --cached , che li rimuove dall'indice lasciandoli sul disco in modo che il servizio possa ancora essere eseguito localmente. Ti commit e spingi quella modifica e i file scompaiono dal repository corrente. Sembra la soluzione. Non lo è, e il passaggio successivo mostra il perché.