Na kratko: Javna mapa .git nastane, ko se spletna stran razmesti prek git clone ali git pull neposredno v webrootu in spletni strežnik skritih map ne blokira. Takrat je mogoče pridobiti celotno izvorno kodo z zgodovino različic vred, vključno z zgodaj vloženimi dostopnimi podatki. Svoje domene preverite s preprostim klicem, dostop takoj blokirajte, razmestitev preusmerite na pakete brez .git in zamenjajte dostopne podatke iz zgodovine.
Izvorna koda za s seboj
Git je standardno orodje za upravljanje različic in za majhne ekipe je smiselno z njim tudi razmeščati: povezava na strežnik, git pull, končano. To deluje zanesljivo in hitro. Ima pa stranski učinek, ki ga pogosto nihče ne opazi.
V imeniku projekta leži skrita mapa .git. Vsebuje ne le aktualno stanje, ampak vsako datoteko v vsaki različici, ki je bila kdaj vložena, poleg tega sporočila commitov, imena in e-poštne naslove razvijalcev ter sklice na strežnike. Če ta mapa leži v webrootu in jo spletni strežnik dostavlja, jo lahko pridobi vsak.
Za napadalce je to darilo. Z izvorno kodo je mogoče ranljivosti iskati ciljno, namesto da bi jih ugibali od zunaj. V zgodovini pa se pogosto najdejo stvari, ki so se zdele že zdavnaj izbrisane: geslo baze podatkov iz začetnega časa, ključ API, testna datoteka s podatki strank.
Je vaša mapa .git javna? Tako preverite
Preverjanje traja sekunde in ničesar ne spreminja. Za vsako domeno in poddomeno kličite datoteko, ki obstaja v vsakem repozitoriju Git:
# Pričakovano: 403 ali 404
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.git/HEAD
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/.git/config
# Na strežniku: ali obstajajo mape .git pod webrooti?
find /var/www /srv/www -maxdepth 4 -type d -name ".git" 2>/dev/null
Status 200 pomeni: mapa je dosegljiva. Pazite tudi na podimenike. Včasih repozitorij ne leži v samem webrootu, ampak v mapi vtičnika ali teme, ki se posebej vzdržuje prek Gita.
Preverite tudi okolja staging in test. Prek Gita se posodabljajo pogosteje kot produkcija in so pogosto dosegljiva na ugibljivih poddomenah.
Takoj: blokirajte dostop
Dokler razmestitev ni spremenjena, pravilo v spletnem strežniku blokira dostop do map sistema za upravljanje različic. Splošna blokada skritih datotek, kot je opisana v prispevku Pravilna zaščita dostopnih podatkov in datotek .env, to pokrije hkrati. Kdor želi ciljno blokirati samo upravljanje različic, uporabi ožje pravilo:
location ~ /\.(git|svn|hg)(/|$) {
return 404;
}
RedirectMatch 404 /\.(git|svn|hg)(/|$)
Nato preverjanje od zgoraj ponovite, in sicer s pravim klicem od zunaj: uspešen preizkus konfiguracije pove samo, da je sintaksa pravilna, ne pa, da pravilo velja pred drugimi pravili za statične datoteke. Pri nadzornih ploščah, kot sta Plesk ali cPanel, pravilo vpišite v predvidene dodatne direktive, da se ob naslednjem ustvarjanju konfiguracije ne izgubi.
Če je bila mapa dosegljiva, vse dostopne podatke, ki so kdaj stali v repozitoriju, obravnavajte kot znane. Samo blokada takrat ne zadošča, vrednosti je treba zamenjati.
Trajno: razmeščanje brez .git v webrootu
Blokada je zaščita, ne rešitev. Trajno upravljanje različic ne sodi na produkcijski strežnik. Preverjene poti, odvisno od vašega okolja:
| Postopek | Kako deluje | Primerno za |
|---|---|---|
| Gradbeni paket iz CI | cevovod zgradi arhiv brez .git, strežnik ga razpakira v nov imenik izdaje |
ekipe s CI/CD |
git archive |
ustvari arhiv stanja brez podatkov o različicah | majhni projekti brez cevovoda |
rsync z izključitvami |
prenese samo potrebne datoteke | klasični strežniki |
| Slika vsebnika | koda se ob gradnji kopira v sliko, .git se izključi prek .dockerignore |
delovanje z vsebniki |
Imenik izdaje za vsako različico s simbolno povezavo na aktualno stanje ima še eno prednost: ob težavah se lahko takoj vrnete. Za nastavitve z vsebniki prispevek CI/CD: samodejna ponovna gradnja slik PHP opisuje, kako postanejo gradnje ponovljive. Tam je treba preveriti tudi, da .git ne pride v sliko.
# Primer: ustvarite paket stanja brez podatkov o različicah
git archive --format=tar.gz -o release.tar.gz HEAD
Druge datoteke projekta, ki ne sodijo v webroot
Mapa .git je najbolj znan primer, a ne edini. Kdor razmešča cele imenike projekta, v webroot prinese še druge datoteke, ki tam nimajo kaj iskati:
- Mape razvojnih okolij, kot sta
.ideaali.vscode, v katerih razširitve za nalaganje datotek včasih shranijo naslove strežnikov in dostopne podatke. composer.jsonincomposer.lock, ki izdata natančne različice vseh knjižnic in s tem olajšata iskanje znanih ranljivosti.- Konfiguracije za teste, gradbena orodja in cevovode, ki razkrivajo notranja imena gostiteljev in postopke.
- Ostanki operacijskih sistemov, kot je
.DS_Store, ki vsebujejo sezname datotek celotnih imenikov.
Rešitev je enaka kot pri mapi .git: dostavljajte samo to, kar mora biti javno, idealno prek lastne podmape kot webroota. Kdor razmestitev tako ali tako preusmerja na pakete, pri tem takoj določi seznam izključenih datotek in ga preveri ob vsakem novem orodju v projektu.
Če je bila mapa odprta: preverite zgodovino in dnevnike
Če se izkaže, da je bila mapa .git dosegljiva, ravnajte v tem vrstnem redu:
- Blokirajte dostop in ponovite preverjanje.
- Preiščite zgodovino, katere skrivnosti so bile kdaj vložene: konfiguracijske datoteke,
.env, ključi, izpisi baze podatkov. - Zamenjajte dostopne podatke, in sicer vse, najdene v koraku 2, tudi če jih danes v kodi ni več.
- Ovrednotite dnevnike dostopa, ali so bile datoteke pod
/.git/klicane s statusom 200 in s katerih naslovov. Kako, kaže Ocena dnevnikov spletnega strežnika po napadu. - Ciljno preglejte izvorno kodo, ker jo napadalci zdaj poznajo. Znane šibkosti naj se odpravijo prednostno.
- Razjasnite varstvo podatkov, če so bili v zgodovini osebni podatki, na primer testni izvozi. Presojo prevzame vaš pooblaščenec za varstvo podatkov.
Orodja za iskanje skrivnosti v repozitorijih sodijo potem trajno v cevovod. OWASP take preglede izrecno priporoča, kot kavelj pred vlaganjem in v CI.
Kako konkretno pomaga PHP SOS?
- Preverimo vse vaše domene in poddomene glede dosegljivih map sistema za upravljanje različic.
- Dostop takoj blokiramo in razmestitev preusmerimo na pakete brez podatkov o različicah.
- Preiščemo zgodovino glede skrivnosti in spremljamo zamenjavo prizadetih dostopov.
- Ovrednotimo dnevnike dostopa in dokumentiramo, ali in kdaj so bili podatki klicani.
Ti ukrepi so del našega utrjevanja strežnikov PHP.
Pogosta vprašanja
Kako nastane javna mapa .git?
Večinoma z razmestitvijo prek git clone ali git pull neposredno v webrootu. Mapa .git s celotno zgodovino različic potem leži ob index.php in brez blokade spletni strežnik dostavlja njene datoteke.
Ali zadošča, da mapo .git izbrišem?
Za prihodnost da, za preteklost ne. Če je bila mapa dosegljiva, je bila vsebina morda že kopirana. Dostopne podatke, ki so kadarkoli stali v repozitoriju, zato zamenjajte.
Ali pomaga, če dostopne podatke naknadno odstranim iz zgodovine Git?
Prepreči, da bi jih vsebovale nove kopije. Kdor je repozitorij že pridobil, stara stanja še naprej ima. Odločilna je zato zamenjava dostopnih podatkov, ne samo prepisovanje zgodovine.
Ali to zadeva tudi druge sisteme za upravljanje različic?
Da. Tudi mape, kot sta .svn ali .hg, vsebujejo podatke projekta in nikoli ne smejo biti dosegljive v webrootu. Splošna blokada datotek in map s piko na začetku pokrije vse te primere.