Lühidalt: Avalik .git-kaust tekib siis, kui veebisait veeretatakse käsuga git clone või git pull otse veebijuurkataloogi välja ja veebiserver peidetud kaustu ei blokeeri. Siis saab kogu lähtekoodi koos versiooniajalooga alla laadida, sealhulgas varakult sisse registreeritud ligipääsuandmed. Kontrollige oma domeene lihtsa päringuga, blokeerige ligipääs kohe, viige juurutus üle pakettidele ilma .git-ita ja vahetage ajaloost pärit ligipääsuandmed välja.
Lähtekood kaasavõtmiseks
Git on versioonihalduse standardtööriist ja väikeste meeskondade jaoks on loomulik sellega ka välja veeretada: serverisse ühenduda, git pull, valmis. See töötab usaldusväärselt ja on kiire. Sellel on aga kõrvalmõju, mida sageli keegi ei märka.
Projektikaustas asub peidetud kaust .git. See sisaldab mitte ainult praegust seisu, vaid iga faili igas versioonis, mis kunagi sisse registreeriti, lisaks commit-sõnumid, arendajate nimed ja e-posti aadressid ning viited serveritele. Kui see kaust asub veebijuurkataloogis ja veebiserver seda edastab, saab igaüks selle alla laadida.
Ründajatele on see kingitus. Lähtekoodiga saab nõrkusi sihipäraselt otsida, selle asemel et neid väljastpoolt ära arvata. Ja ajaloost leiab sageli asju, mis tundusid ammu kustutatud: algusaja andmebaasiparool, API-võti, testfail klientide andmetega.
Kas teie .git-kaust on avalik? Nii kontrollite
Kontroll võtab sekundeid ega muuda midagi. Pärige iga domeeni ja alamdomeeni jaoks fail, mis on olemas igas Giti repositooriumis:
# Oodatud: 403 või 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
# Serveris: kas veebijuurkataloogide all on .git-kaustu?
find /var/www /srv/www -maxdepth 4 -type d -name ".git" 2>/dev/null
Olek 200 tähendab: kaust on kättesaadav. Pöörake tähelepanu ka alamkataloogidele. Vahel ei asu repositoorium veebijuurkataloogis endas, vaid pistikprogrammi või teema kaustas, mida hallatakse eraldi Giti kaudu.
Kontrollige lisaks staging- ja testkeskkondi. Neid uuendatakse Giti kaudu sagedamini kui tootmist ja need on sageli kättesaadavad äraarvatavatel alamdomeenidel.
Kohe: ligipääsu blokeerimine
Kuni juurutus on ümber seadistatud, blokeerib veebiserveri reegel ligipääsu versioonihalduse kaustadele. Üldine blokeering peidetud failidele, nagu on kirjeldatud artiklis Ligipääsuandmete ja .env-failide õige kaitsmine, katab selle samuti. Kes tahab sihipäraselt blokeerida ainult versioonihalduse, kasutab kitsamat reeglit:
location ~ /\.(git|svn|hg)(/|$) {
return 404;
}
RedirectMatch 404 /\.(git|svn|hg)(/|$)
Seejärel korrake ülaltoodud kontrolli, ja päris päringuga väljastpoolt: edukas konfiguratsioonitest ütleb ainult seda, et süntaks on õige, mitte seda, et reegel rakendub enne staatiliste failide muid reegleid. Paneelide, nagu Plesk või cPanel, puhul kirjutage reegel selleks ette nähtud lisadirektiividesse, et see järgmisel konfiguratsiooni genereerimisel kaduma ei läheks.
Kui kaust oli kättesaadav, käsitlege kõiki ligipääsuandmeid, mis kunagi repositooriumis olid, teadaolevatena. Ainult blokeerimisest siis ei piisa, väärtused tuleb välja vahetada.
Püsivalt: välja veeretamine ilma .git-ita veebijuurkataloogis
Blokeering on kaitse, mitte lahendus. Püsivalt ei kuulu versioonihaldus tootmisserverisse. End tõestanud teed, olenevalt teie keskkonnast:
| Meetod | Kuidas see töötab | Sobib |
|---|---|---|
| Build-pakett CI-st | Pipeline ehitab arhiivi ilma .git-ita, server pakib selle uude release-kataloogi |
CI/CD-ga meeskonnad |
git archive |
loob arhiivi ühest seisust ilma versiooniandmeteta | väikesed projektid ilma pipeline'ita |
rsync väljajätetega |
edastab ainult vajalikud failid | klassikalised serverid |
| Konteineri pilt | Kood kopeeritakse ehitamisel pilti, .git jäetakse .dockerignore abil välja |
konteinerites töö |
Release-kataloog iga versiooni jaoks koos sümbolilingiga praegusele seisule annab veel ühe eelise: probleemide korral saate kohe tagasi lülituda. Konteineriseadistuste jaoks kirjeldab CI/CD: PHP piltide automaatne uuesti ehitamine, kuidas ehitused reprodutseeritavaks muutuvad. Seal tuleks kontrollida ka seda, et .git pilti ei satuks.
# Näide: ühe seisu pakett ilma versiooniandmeteta
git archive --format=tar.gz -o release.tar.gz HEAD
Muud projektifailid, mis veebijuurkataloogi ei kuulu
.git-kaust on tuntuim näide, kuid mitte ainus. Kes veeretab välja terved projektikataloogid, toob veebijuurkataloogi veel faile, millel seal asja ei ole:
- Arenduskeskkondade kaustad, nagu
.ideavõi.vscode, kuhu failide üleslaadimise laiendused salvestavad vahel serveriaadresse ja ligipääsuandmeid. composer.jsonjacomposer.lock, mis reedavad kõigi teekide täpsed versioonid ja hõlbustavad seega teadaolevate aukude otsimist.- Testide, build-tööriistade ja pipeline'ide konfiguratsioonid, mis avalikustavad sisemisi hostinimesid ja protsesse.
- Operatsioonisüsteemide jäägid, nagu
.DS_Store, mis sisaldavad kogu kataloogide failinimekirju.
Lahendus on sama mis .git-kausta puhul: edastada ainult see, mis peab avalik olema, ideaalis oma alamkausta kaudu veebijuurkataloogina. Kes viib juurutuse niikuinii üle pakettidele, määrab selle käigus kohe välistatud failide nimekirja ja kontrollib seda iga uue tööriista puhul projektis.
Kui kaust oli avatud: ajaloo ja logide kontroll
Kui selgub, et .git-kaust oli kättesaadav, toimige selles järjekorras:
- Blokeerige ligipääs ja korrake kontrolli.
- Otsige ajaloost läbi, millised saladused on kunagi sisse registreeritud: konfiguratsioonifailid,
.env, võtmed, andmebaasitõmmised. - Vahetage ligipääsuandmed välja, ja kõik, mis sammus 2 leiti, isegi kui need täna enam koodis ei ole.
- Hinnake juurdepääsulogisid, kas faile aadressi
/.git/all päriti olekuga 200 ja millistelt aadressidelt. Kuidas, näitab Veebiserveri logide hindamine pärast rünnakut. - Kontrollige lähtekoodi sihipäraselt, sest ründajad tunnevad seda nüüd. Teadaolevad nõrkused tuleks kõrvaldada esmajärjekorras.
- Selgitage andmekaitse, kui ajaloos oli isikuandmeid, näiteks testeksporte. Hinnangu annab teie andmekaitsespetsialist.
Tööriistad saladuste otsimiseks repositooriumides kuuluvad seejärel püsivalt pipeline'i. OWASP soovitab selliseid kontrolle selgesõnaliselt, konksuna enne sisseregistreerimist ja CI-s.
Kuidas PHP SOS konkreetselt aitab?
- Me kontrollime kõiki teie domeene ja alamdomeene kättesaadavate versioonihalduse kaustade suhtes.
- Me blokeerime ligipääsu kohe ja viime juurutuse üle pakettidele ilma versiooniandmeteta.
- Me otsime ajaloost saladusi ja toetame mõjutatud ligipääsude vahetamist.
- Me hindame juurdepääsulogisid ja dokumenteerime, kas ja millal andmeid päriti.
Need meetmed kuuluvad meie PHP veebiserverite kõvendamise juurde.
Korduma kippuvad küsimused
Kuidas avalik .git-kaust tekib?
Enamasti juurutusega käsuga git clone või git pull otse veebijuurkataloogis. Kaust .git kogu versiooniajalooga asub siis index.php kõrval ja ilma blokeeringuta edastab veebiserver selle faile.
Kas .git-kausta kustutamisest piisab?
Tuleviku jaoks jah, mineviku jaoks mitte. Kui kaust oli kättesaadav, võidi sisu juba kopeerida. Ligipääsuandmed, mis kunagi repositooriumis olid, peaksite seetõttu välja vahetama.
Kas aitab ligipääsuandmete tagantjärele Giti ajaloost eemaldamine?
See takistab, et uued koopiad neid sisaldaksid. Kes on repositooriumi juba kätte saanud, omab vanu seisusid edasi. Otsustav on seetõttu ligipääsuandmete vahetamine, mitte ainult ajaloo ümberkirjutamine.
Kas see puudutab ka teisi versioonihaldussüsteeme?
Jah. Ka kaustad, nagu .svn või .hg, sisaldavad projektiandmeid ega tohi kunagi veebijuurkataloogis kättesaadavad olla. Üldine blokeering punktiga algavatele failidele ja kaustadele katab kõik need juhud.