Röviden: Nyilvános .git mappa akkor keletkezik, ha egy weboldalt git clone vagy git pull útján közvetlenül a webrootban telepítenek, és a webszerver nem tiltja a rejtett mappákat. Ilyenkor a teljes forráskód a verziótörténettel együtt lekérhető, beleértve a korábban bejegyzett hozzáférési adatokat. Egy egyszerű hívással ellenőrizze a domainjeit, azonnal tiltsa le a hozzáférést, állítsa át a telepítést .git nélküli csomagokra, és cserélje ki az előzményekben szereplő hozzáférési adatokat.
A forráskód elvihetően
A Git a verziókezelés alapeszköze, és kis csapatoknál kézenfekvő, hogy vele telepítsenek is: csatlakozni a szerverre, git pull, kész. Ez megbízhatóan működik és gyors. Van viszont egy mellékhatása, amelyet gyakran senki sem vesz észre.
A projektmappában ott van egy rejtett .git mappa. Nemcsak az aktuális állapotot tartalmazza, hanem minden valaha bejegyzett fájlt minden verzióban, továbbá a commit-üzeneteket, a fejlesztők nevét és e-mail-címét, valamint szerverekre mutató hivatkozásokat. Ha ez a mappa a webrootban van, és a webszerver kiszolgálja, bárki lekérheti.
A támadóknak ez ajándék. A forráskóddal célzottan kereshetnek sebezhetőségeket, ahelyett hogy kívülről találgatnák őket. Az előzményekben pedig gyakran olyasmik vannak, amiket már régen töröltnek hittek: egy kezdeti időkből származó adatbázis-jelszó, egy API-kulcs, egy ügyféladatokat tartalmazó tesztfájl.
Nyilvános az Ön .git mappája? Így ellenőrizze
Az ellenőrzés másodpercekig tart, és semmit sem módosít. Minden domainre és aldomainre hívjon le egy olyan fájlt, amely minden Git-repositoryban létezik:
# Várt eredmény: 403 vagy 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
# A szerveren: vannak .git mappák a webrootok alatt?
find /var/www /srv/www -maxdepth 4 -type d -name ".git" 2>/dev/null
A 200-as állapot azt jelenti: a mappa elérhető. Ügyeljen az alkönyvtárakra is. Néha a repository nem magában a webrootban van, hanem egy külön Gittel karbantartott bővítmény- vagy téma-mappában.
Ellenőrizze emellett a staging és tesztkörnyezeteket. Ezeket gyakrabban frissítik Gittel, mint az éles rendszert, és gyakran kitalálható aldomainek alatt érhetők el.
Azonnal: a hozzáférés tiltása
Amíg a telepítés át nincs állítva, a webszerver egyik szabálya tiltja a hozzáférést a verziókezelés mappáihoz. A rejtett fájlokra vonatkozó általános tiltás, ahogyan a Hozzáférési adatok és .env fájlok helyes védelme leírja, ezt is lefedi. Aki célzottan csak a verziókezelést akarja tiltani, szűkebb szabályt használ:
location ~ /\.(git|svn|hg)(/|$) {
return 404;
}
RedirectMatch 404 /\.(git|svn|hg)(/|$)
Utána ismételje meg a fenti ellenőrzést, mégpedig valódi, kívülről végzett hívással: egy sikeres konfigurációs teszt csak azt mondja, hogy a szintaxis stimmel, nem azt, hogy a szabály a statikus fájlokra vonatkozó más szabályok előtt érvényesül. Az olyan paneleknél, mint a Plesk vagy a cPanel, a szabályt a erre szolgáló további direktívákba írja be, hogy a következő konfiguráció-generáláskor ne vesszen el.
Ha a mappa elérhető volt, kezelje ismertként az összes hozzáférési adatot, amely valaha a repositoryban szerepelt. A tiltás önmagában ekkor nem elég, az értékeket ki kell cserélni.
Tartósan: telepítés .git nélkül a webrootban
A tiltás biztosíték, nem megoldás. Tartósan a verziókezelés nem való az éles szerverre. Bevált utak, a környezetétől függően:
| Eljárás | Hogyan működik | Kinek megfelelő |
|---|---|---|
| Build-csomag a CI-ból | a pipeline .git nélküli archívumot épít, a szerver egy új release-könyvtárba csomagolja ki |
CI/CD-s csapatok |
git archive |
verzióadatok nélküli archívumot hoz létre egy állapotról | pipeline nélküli kis projektek |
rsync kizárásokkal |
csak a szükséges fájlokat viszi át | klasszikus szerverek |
| Konténerkép | a kódot építéskor másolja a képbe, a .git-et a .dockerignore zárja ki |
konténeres üzem |
A verziónkénti release-könyvtárnak, az aktuális állapotra mutató szimbolikus linkkel, további előnye van: problémák esetén azonnal visszakapcsolhat. Konténeres környezetekhez a CI/CD: PHP-képek automatikus újraépítése leírja, hogyan lesznek az buildek reprodukálhatók. Ott azt is ellenőrizni kell, hogy a .git ne kerüljön a képbe.
# Példa: verzióadatok nélküli csomag létrehozása egy állapotról
git archive --format=tar.gz -o release.tar.gz HEAD
További projektfájlok, amelyek nem a webrootba valók
A .git mappa a legismertebb példa, de nem az egyetlen. Aki egész projektkönyvtárakat telepít, további fájlokat hoz a webrootba, amelyeknek ott semmi keresnivalójuk nincs:
- Fejlesztői környezetek mappái, mint a
.ideavagy a.vscode, amelyekben a fájlfeltöltő bővítmények olykor szerver-címeket és hozzáférési adatokat tárolnak. - A
composer.jsonés acomposer.lock, amelyek elárulják az összes könyvtár pontos verzióját, és ezzel megkönnyítik az ismert rések keresését. - Tesztek, build-eszközök és pipeline-ok konfigurációi, amelyek belső hosztneveket és folyamatokat tárnak fel.
- Operációs rendszerek maradványai, mint a
.DS_Store, amelyek egész könyvtárak fájllistáit tartalmazzák.
A megoldás ugyanaz, mint a .git mappánál: csak azt kiszolgálni, aminek nyilvánosnak kell lennie, ideális esetben egy saját almappa mint webroot által. Aki a telepítést amúgy is csomagokra állítja át, rögtön kizárt fájlok listáját is megadja, és a projekt minden új eszközénél ellenőrzi.
Ha a mappa nyitva volt: az előzmények és a naplók ellenőrzése
Ha kiderül, hogy a .git mappa elérhető volt, ebben a sorrendben járjon el:
- A hozzáférés tiltása, és az ellenőrzés megismétlése.
- Az előzmények átvizsgálása arra, hogy mely titkokat jegyezték be valaha: konfigurációs fájlokat,
.env-et, kulcsokat, adatbázis-dumpokat. - A hozzáférési adatok cseréje, mégpedig mindegyiké, amelyet a 2. lépésben találtak, még ha ma már nincsenek is a kódban.
- A hozzáférési naplók kiértékelése arra, hogy a
/.git/alatti fájlokat 200-as állapottal lekérték-e, és mely címekről. Hogyan megy ez, azt a Webszerver-naplók kiértékelése egy támadás után mutatja. - A forráskód célzott ellenőrzése, mert a támadók most már ismerik. Az ismert gyengeségeket elsőbbséggel kell megszüntetni.
- Az adatvédelem tisztázása, ha személyes adatok voltak az előzményekben, például tesztexportok. Az értékelést az adatvédelmi tisztviselője végzi.
A titkok keresésére szolgáló eszközök ezután tartósan a pipeline-ba tartoznak. Az OWASP kifejezetten ajánlja az ilyen ellenőrzéseket, hookként a bejegyzés előtt és a CI-ban.
Hogyan segít konkrétan a PHP SOS?
- Ellenőrizzük az összes domainjét és aldomainjét elérhető verziókezelő-mappák után.
- Azonnal tiltjuk a hozzáférést, és a telepítést verzióadatok nélküli csomagokra állítjuk át.
- Átvizsgáljuk az előzményeket titkok után, és kísérjük az érintett hozzáférések cseréjét.
- Kiértékeljük a hozzáférési naplókat, és dokumentáljuk, hogy lekértek-e adatokat, és mikor.
Ezek az intézkedések a PHP-webszerverek keményítésének részei.
Gyakori kérdések
Hogyan keletkezik nyilvános .git mappa?
Többnyire git clone vagy git pull útján végzett telepítéssel közvetlenül a webrootban. A teljes verziótörténetet tartalmazó .git mappa ekkor az index.php mellett van, és tiltás nélkül a webszerver kiszolgálja a fájljait.
Elég a .git mappát törölni?
A jövőre nézve igen, a múltra nézve nem. Ha a mappa elérhető volt, a tartalmát már lemásolhatták. A hozzáférési adatokat, amelyek valaha a repositoryban álltak, ezért cserélje ki.
Segít, ha utólag eltávolítja a hozzáférési adatokat a Git-előzményekből?
Megakadályozza, hogy az új másolatok tartalmazzák őket. Aki a repositoryt már lekérte, a régi állapotokat továbbra is birtokolja. Ezért a hozzáférési adatok cseréje a döntő, nem csupán az előzmények átírása.
Érinti ez a többi verziókezelőt is?
Igen. Az olyan mappák, mint a .svn vagy a .hg, szintén projektadatokat tartalmaznak, és soha nem szabad elérhetőnek lenniük a webrootban. A ponttal kezdődő fájlokra és mappákra vonatkozó általános tiltás mindezeket az eseteket lefedi.