Kurz gesagt: Ein öffentlicher .git-Ordner entsteht, wenn eine Website per git clone oder git pull direkt im Webroot ausgerollt wird und der Webserver versteckte Ordner nicht sperrt. Dann lässt sich der komplette Quellcode samt Versionsgeschichte abrufen, einschließlich früher eingecheckter Zugangsdaten. Prüfen Sie Ihre Domains mit einem einfachen Aufruf, sperren Sie den Zugriff sofort, stellen Sie das Deployment auf Pakete ohne .git um und tauschen Sie Zugangsdaten aus der Historie aus.
Der Quellcode zum Mitnehmen
Git ist das Standardwerkzeug für Versionsverwaltung, und für kleine Teams ist es naheliegend, damit auch auszurollen: auf den Server verbinden, git pull, fertig. Das funktioniert zuverlässig und ist schnell. Es hat aber eine Nebenwirkung, die oft niemand bemerkt.
Im Projektordner liegt ein versteckter Ordner .git. Er enthält nicht nur den aktuellen Stand, sondern jede Datei in jeder Version, die jemals eingecheckt wurde, dazu Commit-Nachrichten, Namen und E-Mail-Adressen der Entwickler und Verweise auf Server. Liegt dieser Ordner im Webroot und liefert der Webserver ihn aus, kann jeder ihn abrufen.
Für Angreifer ist das ein Geschenk. Mit dem Quellcode lassen sich Schwachstellen gezielt suchen, statt sie von außen zu erraten. Und in der Historie finden sich häufig Dinge, die längst gelöscht schienen: ein Datenbankpasswort aus der Anfangszeit, ein API-Schlüssel, eine Testdatei mit Kundendaten.
Ist Ihr .git-Ordner öffentlich? So prüfen Sie es
Die Prüfung dauert Sekunden und verändert nichts. Rufen Sie für jede Domain und Subdomain eine Datei auf, die in jedem Git-Repository existiert:
# Erwartet: 403 oder 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
# Auf dem Server: Gibt es .git-Ordner unterhalb der Webroots?
find /var/www /srv/www -maxdepth 4 -type d -name ".git" 2>/dev/null
Ein Status 200 bedeutet: Der Ordner ist erreichbar. Achten Sie auch auf Unterverzeichnisse. Manchmal liegt das Repository nicht im Webroot selbst, sondern in einem Plugin- oder Theme-Ordner, der separat per Git gepflegt wird.
Prüfen Sie außerdem Staging- und Testumgebungen. Sie werden häufiger per Git aktualisiert als die Produktion und sind oft unter erratbaren Subdomains erreichbar.
Sofort: den Zugriff sperren
Bis das Deployment umgestellt ist, sperrt eine Regel im Webserver den Zugriff auf Ordner der Versionsverwaltung. Eine allgemeine Sperre für versteckte Dateien, wie in Zugangsdaten und .env-Dateien richtig schützen beschrieben, deckt das mit ab. Wer gezielt nur die Versionsverwaltung sperren will, nutzt eine engere Regel:
location ~ /\.(git|svn|hg)(/|$) {
return 404;
}
RedirectMatch 404 /\.(git|svn|hg)(/|$)
Danach die Prüfung von oben wiederholen, und zwar mit einem echten Aufruf von außen: Ein erfolgreicher Konfigurationstest sagt nur, dass die Syntax stimmt, nicht, dass die Regel vor anderen Regeln für statische Dateien greift. Bei Panels wie Plesk oder cPanel tragen Sie die Regel in die dafür vorgesehenen zusätzlichen Direktiven ein, damit sie bei der nächsten Konfigurationserzeugung nicht verloren geht.
War der Ordner erreichbar, behandeln Sie alle Zugangsdaten, die jemals im Repository standen, als bekannt. Sperren allein reicht dann nicht, die Werte müssen ausgetauscht werden.
Dauerhaft: ausrollen ohne .git im Webroot
Die Sperre ist eine Absicherung, keine Lösung. Dauerhaft gehört die Versionsverwaltung nicht auf den Produktionsserver. Bewährte Wege, abhängig von Ihrer Umgebung:
| Verfahren | Wie es funktioniert | Geeignet für |
|---|---|---|
| Build-Paket aus der CI | Pipeline baut ein Archiv ohne .git, Server entpackt es in ein neues Release-Verzeichnis |
Teams mit CI/CD |
git archive |
erzeugt ein Archiv eines Stands ohne Versionsdaten | kleine Projekte ohne Pipeline |
rsync mit Ausschlüssen |
überträgt nur die nötigen Dateien | klassische Server |
| Container-Image | Code wird beim Bau ins Image kopiert, .git per .dockerignore ausgeschlossen |
Container-Betrieb |
Ein Release-Verzeichnis je Version mit einem symbolischen Link auf den aktuellen Stand hat einen weiteren Vorteil: Sie können bei Problemen sofort zurückschalten. Für Container-Setups beschreibt CI/CD: PHP-Images automatisch neu bauen, wie Builds reproduzierbar werden. Dort sollte auch geprüft werden, dass .git nicht ins Image gelangt.
# Beispiel: Paket eines Stands ohne Versionsdaten erzeugen
git archive --format=tar.gz -o release.tar.gz HEAD
Weitere Projektdateien, die nicht in den Webroot gehören
Der .git-Ordner ist das bekannteste Beispiel, aber nicht das einzige. Wer ganze Projektverzeichnisse ausrollt, bringt weitere Dateien in den Webroot, die dort nichts zu suchen haben:
- Ordner von Entwicklungsumgebungen wie
.ideaoder.vscode, in denen Erweiterungen für den Datei-Upload mitunter Serveradressen und Zugangsdaten speichern. composer.jsonundcomposer.lock, die genaue Versionen aller Bibliotheken verraten und damit die Suche nach bekannten Lücken erleichtern.- Konfigurationen für Tests, Build-Werkzeuge und Pipelines, die interne Hostnamen und Abläufe preisgeben.
- Reste von Betriebssystemen wie
.DS_Store, die Dateilisten ganzer Verzeichnisse enthalten.
Die Lösung ist dieselbe wie beim .git-Ordner: nur ausliefern, was öffentlich sein muss, idealerweise über einen eigenen Unterordner als Webroot. Wer das Deployment ohnehin auf Pakete umstellt, legt dabei gleich eine Liste ausgeschlossener Dateien fest und prüft sie bei jedem neuen Werkzeug im Projekt.
Wenn der Ordner offen war: Historie und Protokolle prüfen
Stellt sich heraus, dass der .git-Ordner erreichbar war, gehen Sie in dieser Reihenfolge vor:
- Zugriff sperren und Prüfung wiederholen.
- Historie durchsuchen, welche Geheimnisse jemals eingecheckt wurden: Konfigurationsdateien,
.env, Schlüssel, Datenbank-Dumps. - Zugangsdaten austauschen, und zwar alle, die in Schritt 2 gefunden wurden, auch wenn sie heute nicht mehr im Code stehen.
- Zugriffsprotokolle auswerten, ob Dateien unter
/.git/mit Status 200 abgerufen wurden und von welchen Adressen. Wie das geht, zeigt Webserver-Logs nach einem Angriff auswerten. - Quellcode gezielt prüfen, denn Angreifer kennen ihn jetzt. Bekannte Schwächen sollten vorrangig behoben werden.
- Datenschutz klären, falls personenbezogene Daten in der Historie lagen, etwa Testexporte. Die Bewertung übernimmt Ihr Datenschutzbeauftragter.
Werkzeuge zur Suche nach Geheimnissen in Repositories gehören danach dauerhaft in die Pipeline. OWASP empfiehlt solche Prüfungen ausdrücklich, als Hook vor dem Einchecken und in der CI.
Wie hilft PHP SOS konkret?
- Wir prüfen alle Ihre Domains und Subdomains auf erreichbare Ordner der Versionsverwaltung.
- Wir sperren den Zugriff sofort und stellen das Deployment auf Pakete ohne Versionsdaten um.
- Wir durchsuchen die Historie nach Geheimnissen und begleiten den Austausch der betroffenen Zugänge.
- Wir werten die Zugriffsprotokolle aus und dokumentieren, ob und wann Daten abgerufen wurden.
Diese Maßnahmen sind Teil unserer Server-Härtung für PHP-Webserver.
Häufige Fragen
Wie entsteht ein öffentlicher .git-Ordner?
Meist durch ein Deployment per git clone oder git pull direkt im Webroot. Der Ordner .git mit der gesamten Versionsgeschichte liegt dann neben index.php, und ohne Sperre liefert der Webserver seine Dateien aus.
Reicht es, den .git-Ordner zu löschen?
Für die Zukunft ja, für die Vergangenheit nicht. Wenn der Ordner erreichbar war, kann der Inhalt bereits kopiert worden sein. Zugangsdaten, die irgendwann im Repository standen, sollten Sie deshalb austauschen.
Hilft es, Zugangsdaten nachträglich aus der Git-Historie zu entfernen?
Es verhindert, dass neue Kopien sie enthalten. Wer das Repository bereits abgerufen hat, besitzt die alten Stände weiterhin. Entscheidend ist deshalb der Austausch der Zugangsdaten, nicht nur das Umschreiben der Historie.
Betrifft das auch andere Versionsverwaltungen?
Ja. Auch Ordner wie .svn oder .hg enthalten Projektdaten und sollten nie im Webroot erreichbar sein. Eine allgemeine Sperre für Dateien und Ordner mit Punkt am Anfang deckt alle diese Fälle ab.