Geheimen in de Git-geschiedenis

Wat is Geheimen in de Git-geschiedenis?

Het verwijderen van een hardcoded credential in een nieuwe commit verwijdert deze niet. Git bewaart elke versie van elk bestand, dus de waarde zit nog steeds in de commit vóór het opschonen. De huidige code ziet er schoon uit en daarom blijven deze lekken jarenlang bestaan. Je zult de commit vinden die beweert een productie-API-sleutel te hebben verwijderd, deze eerder uit de commit lezen en deze opnieuw afspelen met de live admin-API. Vervolgens ga je de geschiedenis opschonen met git filter-repo, met opzet in de verkeerde volgorde, en leer je waarom rotatie op de eerste plaats komt.

Wat je leert in Geheimen in de Git-geschiedenis

• Erken dat het verwijderen van een hardgecodeerd geheim in een nieuwe commit het niet verwijdert: git behoudt de waarde in elke eerdere commit en in de reflog, zodat iedereen die de repository kloont het kan lezen
• Volg het pad van een aanvaller, van het klonen van een openbare opslagplaats, tot het weergeven van de commitgeschiedenis van een bestand, tot het tonen van de commit vóór verwijdering, tot het opnieuw afspelen van een live API-sleutel die nooit is gerouleerd
• Begrijp dat het herschrijven van de geschiedenis een geheim dat al is gekloond of gescand niet kan oproepen, dus het roteren van de referentie is de enige stap die de gelekte waarde daadwerkelijk ongeldig maakt
• Geef prioriteit aan het roteren van referenties als de primaire oplossing en pas het herschrijven van de geschiedenis toe met git filter-repo of BFG en een geforceerde update op afstand om het geheim uit elke commit te verwijderen als opschoning, niet als de oplossing
• Voorkom herhaling door geheimen uit de bron te houden met omgevingsvariabelen en een pre-commit hook voor het scannen van geheimen toe te voegen, zodat een referentie wordt geblokkeerd voordat deze ooit in de geschiedenis van de repository terechtkomt

Geheimen in de Git-geschiedenis — Trainingsstappen

1. Maak het doel groter

   Vandaag richt Bob zich op Larkfell, een ontwikkelaarsplatformbedrijf dat veel van zijn werk in de open lucht uitvoert. Hij begint waar iedereen dat zou doen: in de publieke repository, en inventariseert wat het bedrijf verzendt voordat hij op zoek gaat naar een manier om binnen te komen. Een open-source repository is een geschenk aan iemand als Bob: het hele project, elk bestand en elke versie van elk bestand, allemaal downloadbaar.

2. Kloon de opslagplaats

   Bob kloont de repository naar zijn eigen machine, zodat hij het hele project in zijn eigen tempo offline kan doorzoeken. De kloon die hij naar beneden haalt, bestaat niet alleen uit de huidige bestanden. Het is de hele geschiedenis, en dat is precies wat hij zoekt.

3. Controleer de huidige code

   Voordat hij gaat graven, doet Bob wat een zorgvuldige recensent zou doen: hij opent de huidige productieconfiguratie om te zien of er nog iets voor de hand liggends in zit. Het is schoon. De admin-sleutel wordt gelezen vanuit een omgevingsvariabele en niet in het bestand geschreven, dus hier is niets hardgecodeerd. Een casual look zou daar stoppen.

4. Bewandel de geschiedenis

   Een schoon dossier bij HEAD zegt niets over het verleden. De sleutel is verdwenen uit de huidige code, maar git heeft elke eerdere versie van dat bestand behouden. Bob weet dit, dus somt hij de commitgeschiedenis van de configuratie op om te zien wat deze vroeger bevatte, niet alleen wat er nu in zit.

5. De sleutel is er nog

   Bob laat de commit zien die de configuratie heeft toegevoegd, die vlak voor het opruimen. De verwijderingscommit heeft de regel uit de huidige code verwijderd, maar deze eerdere commit bevat deze nog steeds. De API-sleutel voor de productiebeheerder bevindt zich in platte tekst in de diff, precies zoals deze was voordat iemand hem probeerde te verwijderen.

6. De sleutel werkt nog

   Een gelekte sleutel is slechts een theorie totdat hij iets opent. Bob wijst de herstelde sleutel naar de admin-API van Larkfell en draagt ​​deze in een Authorization-header zoals een echte klant dat zou doen. De sleutel is nooit gerouleerd na de opschoonopdracht, dus de waarde van die oude commit is nog steeds actief.

7. De klantenlijst is geopend

   De server vertrouwde de sleutel en antwoordde. Bob leest de interne klantenlijst van Larkfell via een openbare API, zonder dat hij zelf een account heeft.

8. Kennis check

   Je hebt zojuist gezien hoe een verwijderd geheim nog steeds een productie-API opende. Leg vast waarom.

9. De waarschuwing komt binnen

   U bezit de backend-repository van Larkfell. Van de ene op de andere dag heeft de geheime scanservice die uw openbare opslagplaatsen in de gaten houdt, een waarschuwing afgegeven en deze naar u gemaild. De bevinding is bot: er is een API-sleutel voor liveproductie aanwezig in de openbare commitgeschiedenis. Het staat niet in de huidige code, maar de scanner heeft de geschiedenis doorzocht en gevonden in een eerdere commit.

10. Verdwenen uit HOOFD, levend in de geschiedenis

    Je eerste instinct is om de huidige code te controleren, en de sleutel is echt verdwenen uit HEAD. Iemand heeft de regel al verwijderd in een latere commit. Dat hielp niet. Je laat de eerdere commit zelf zien, en de live-sleutel wordt meteen afgedrukt. Het overleeft in elke commit die het nog steeds bevat, dus door de regel uit de nieuwste versie te verwijderen, bleef de referentie volledig leesbaar voor iedereen die de repository heeft gekloond.