# Nyilvános .git mappa: egy alábecsült adatszivárgás

> Nyilvános az Ön .git mappája? Így ellenőrizze, tiltsa le a hozzáférést, állítsa át a telepítést, és kezelje az előzményekben lévő hozzáférési adatokat.

Forrás: https://phpsos.de/hu/blog/git-ordner-oeffentlich/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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:

```bash
# 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](https://phpsos.de/hu/blog/env-dateien-schuetzen/) leírja, ezt is lefedi. Aki célzottan csak a verziókezelést akarja tiltani, szűkebb szabályt használ:

```nginx
location ~ /\.(git|svn|hg)(/|$) {
    return 404;
}
```

```apache
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.

> **Azonnal cselekedjen:**
> 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](https://phpsos.de/hu/blog/php-images-in-ci-neu-bauen/) 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.

```bash
# 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 `.idea` vagy 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 a `composer.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:

1. **A hozzáférés tiltása**, és az ellenőrzés megismétlése.
2. **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.
3. **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.
4. **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](https://phpsos.de/hu/ratgeber/logfiles-auswerten/) mutatja.
5. **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.
6. **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](https://phpsos.de/hu/leistungen/server-haertung/) 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.

## Források

- [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)
- [Nginx dokumentáció](https://nginx.org/en/docs/)
- [Apache HTTP Server: dokumentáció](https://httpd.apache.org/docs/)