Lyhyesti: Julkinen .git-kansio syntyy, kun verkkosivusto otetaan käyttöön komennolla git clone tai git pull suoraan verkkojuuressa eikä verkkopalvelin estä piilokansioita. Silloin koko lähdekoodi versiohistorioineen on haettavissa, mukaan lukien aiemmin versionhallintaan viedyt tunnukset. Tarkistakaa verkkotunnuksenne yksinkertaisella kutsulla, estäkää pääsy heti, siirtäkää käyttöönotto paketteihin ilman .git-kansiota ja vaihtakaa historiassa olleet tunnukset.
Lähdekoodi mukaan otettavaksi
Git on versionhallinnan vakiotyökalu, ja pienille tiimeille on luontevaa käyttää sitä myös käyttöönotossa: yhteys palvelimelle, git pull, valmis. Se toimii luotettavasti ja on nopeaa. Sillä on kuitenkin sivuvaikutus, jota usein kukaan ei huomaa.
Projektikansiossa on piilotettu kansio .git. Se sisältää paitsi nykyisen tilan myös jokaisen tiedoston jokaisen koskaan versionhallintaan viedyn version, lisäksi commit-viestit, kehittäjien nimet ja sähköpostiosoitteet sekä viittauksia palvelimiin. Jos tämä kansio on verkkojuuressa ja verkkopalvelin tarjoilee sen, kuka tahansa voi hakea sen.
Hyökkääjälle se on lahja. Lähdekoodin avulla heikkouksia voi etsiä kohdennetusti sen sijaan, että niitä arvailtaisiin ulkopuolelta. Ja historiasta löytyy usein asioita, jotka näyttivät jo poistetuilta: alkuaikojen tietokannan salasana, API-avain, testitiedosto asiakastiedoilla.
Onko .git-kansionne julkinen? Näin tarkistatte
Tarkistus kestää sekunteja eikä muuta mitään. Kutsukaa jokaiselle verkkotunnukselle ja aliverkkotunnukselle tiedostoa, joka on olemassa jokaisessa Git-repositoriossa:
# Odotettu tulos: 403 tai 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
# Palvelimella: onko verkkojuurten alla .git-kansioita?
find /var/www /srv/www -maxdepth 4 -type d -name ".git" 2>/dev/null
Tila 200 tarkoittaa: kansio on saavutettavissa. Kiinnittäkää huomiota myös alihakemistoihin. Joskus repositorio ei ole itse verkkojuuressa vaan laajennus- tai teemakansiossa, jota ylläpidetään erikseen Gitillä.
Tarkistakaa lisäksi staging- ja testiympäristöt. Niitä päivitetään Gitillä useammin kuin tuotantoa, ja ne ovat usein saavutettavissa arvattavilla aliverkkotunnuksilla.
Heti: estä pääsy
Siihen asti, kunnes käyttöönotto on muutettu, verkkopalvelimen sääntö estää pääsyn versionhallinnan kansioihin. Piilotiedostojen yleinen esto, kuten kirjoituksessa Tunnusten ja .env-tiedostojen oikea suojaus kuvataan, kattaa tämän samalla. Joka haluaa estää kohdennetusti vain versionhallinnan, käyttää suppeampaa sääntöä:
location ~ /\.(git|svn|hg)(/|$) {
return 404;
}
RedirectMatch 404 /\.(git|svn|hg)(/|$)
Toistakaa sen jälkeen yllä oleva tarkistus, ja nimenomaan oikealla kutsulla ulkopuolelta: onnistunut konfiguraatiotesti kertoo vain, että syntaksi on oikein, ei sitä, että sääntö toimii ennen muita staattisten tiedostojen sääntöjä. Paneeleissa kuten Plesk tai cPanel kirjatkaa sääntö niille tarkoitettuihin lisädirektiiveihin, jotta se ei katoa seuraavassa konfiguraation luonnissa.
Jos kansio oli saavutettavissa, käsitelkää kaikkia tunnuksia, jotka ovat koskaan olleet repositoriossa, tunnettuina. Pelkkä esto ei silloin riitä, arvot on vaihdettava.
Pysyvästi: käyttöönotto ilman .git-kansiota verkkojuuressa
Esto on suojatoimi, ei ratkaisu. Pysyvästi versionhallinta ei kuulu tuotantopalvelimelle. Hyväksi havaitut tavat ympäristöstänne riippuen:
| Menettely | Miten se toimii | Sopii |
|---|---|---|
| Build-paketti CI:stä | putki rakentaa arkiston ilman .git-kansiota, palvelin purkaa sen uuteen julkaisuhakemistoon |
tiimeille, joilla on CI/CD |
git archive |
luo tilan arkiston ilman versiotietoja | pienille projekteille ilman putkea |
rsync poissulkemisilla |
siirtää vain tarvittavat tiedostot | perinteisille palvelimille |
| Konttikuva | koodi kopioidaan imageen rakennettaessa, .git suljetaan pois tiedostolla .dockerignore |
konttikäyttöön |
Versiokohtaisella julkaisuhakemistolla ja symbolisella linkillä nykyiseen tilaan on vielä yksi etu: ongelmien sattuessa voitte palata heti takaisin. Konttiympäristöissä kirjoitus CI/CD: PHP-imagejen automaattinen uudelleenrakennus kuvaa, miten buildeista tehdään toistettavia. Siellä tulisi myös tarkistaa, ettei .git päädy imageen.
# Esimerkki: luo tilan paketti ilman versiotietoja
git archive --format=tar.gz -o release.tar.gz HEAD
Muita projektitiedostoja, jotka eivät kuulu verkkojuureen
.git-kansio on tunnetuin esimerkki, mutta ei ainoa. Joka ottaa käyttöön kokonaisia projektihakemistoja, tuo verkkojuureen muitakin tiedostoja, joilla ei ole siellä mitään asiaa:
- Kehitysympäristöjen kansiot kuten
.ideatai.vscode, joihin tiedostolatauslaajennukset tallentavat toisinaan palvelinosoitteita ja tunnuksia. composer.jsonjacomposer.lock, jotka paljastavat kaikkien kirjastojen tarkat versiot ja helpottavat siten tunnettujen aukkojen etsintää.- Testien, build-työkalujen ja putkien konfiguraatiot, jotka paljastavat sisäisiä isäntänimiä ja toimintatapoja.
- Käyttöjärjestelmien jäänteet kuten
.DS_Store, jotka sisältävät kokonaisten hakemistojen tiedostoluettelot.
Ratkaisu on sama kuin .git-kansiossa: tarjoilkaa vain se, minkä on oltava julkista, mieluiten omalla alikansiolla verkkojuurena. Joka muuttaa käyttöönoton joka tapauksessa paketteihin, määrittelee samalla luettelon poissuljetuista tiedostoista ja tarkistaa sen jokaisen projektiin tulevan uuden työkalun kohdalla.
Jos kansio oli auki: historian ja lokien tarkistus
Jos käy ilmi, että .git-kansio oli saavutettavissa, edetkää tässä järjestyksessä:
- Estäkää pääsy ja toistakaa tarkistus.
- Käykää historia läpi: mitä salaisuuksia on koskaan viety versionhallintaan: asetustiedostot,
.env, avaimet, tietokantavedokset. - Vaihtakaa tunnukset, ja nimenomaan kaikki, jotka löytyivät vaiheessa 2, vaikka ne eivät enää olisi koodissa.
- Analysoikaa käyttölokit: haettiinko tiedostoja polusta
/.git/tilalla 200 ja miltä osoitteilta. Miten se tehdään, näyttää Verkkopalvelimen lokien analysointi hyökkäyksen jälkeen. - Tarkistakaa lähdekoodi kohdennetusti, sillä hyökkääjät tuntevat sen nyt. Tunnetut heikkoudet tulisi korjata ensisijaisesti.
- Selvittäkää tietosuoja, jos historiassa oli henkilötietoja, esimerkiksi testivientejä. Arvioinnin hoitaa tietosuojavastaavanne.
Salaisuuksien etsintätyökalut repositorioissa kuuluvat sen jälkeen pysyvästi putkeen. OWASP suosittelee tällaisia tarkistuksia nimenomaisesti, koukkuna ennen versionhallintaan viemistä ja CI:ssä.
Miten PHP SOS auttaa konkreettisesti?
- Tarkistamme kaikki verkkotunnuksenne ja aliverkkotunnuksenne saavutettavien versionhallintakansioiden varalta.
- Estämme pääsyn heti ja muutamme käyttöönoton paketteihin ilman versiotietoja.
- Käymme historian läpi salaisuuksien varalta ja tuemme asianomaisten tunnusten vaihtoa.
- Analysoimme käyttölokit ja dokumentoimme, haettiinko tietoja ja milloin.
Nämä toimenpiteet kuuluvat PHP-verkkopalvelinten koventamiseemme.
Usein kysytyt kysymykset
Miten julkinen .git-kansio syntyy?
Yleensä käyttöönotolla komennolla git clone tai git pull suoraan verkkojuuressa. Kansio .git koko versiohistorioineen on silloin index.php:n vieressä, ja ilman estoa verkkopalvelin tarjoilee sen tiedostot.
Riittääkö .git-kansion poistaminen?
Tulevaisuuden kannalta kyllä, menneisyyden kannalta ei. Jos kansio oli saavutettavissa, sisältö on voitu jo kopioida. Tunnukset, jotka ovat joskus olleet repositoriossa, kannattaa siksi vaihtaa.
Auttaako tunnusten poistaminen Git-historiasta jälkikäteen?
Se estää uusia kopioita sisältämästä niitä. Joka on jo hakenut repositorion, omistaa vanhat tilat edelleen. Ratkaisevaa on siksi tunnusten vaihto, ei pelkkä historian uudelleenkirjoitus.
Koskeeko tämä myös muita versionhallintajärjestelmiä?
Kyllä. Myös kansiot kuten .svn tai .hg sisältävät projektitietoja, eivätkä ne saa koskaan olla saavutettavissa verkkojuuressa. Pisteellä alkavien tiedostojen ja kansioiden yleinen esto kattaa kaikki nämä tapaukset.