Offene .env-, .git- und Backup-Dateien: wie Geheimnisse von Websites abfließen

Manche der folgenreichsten Lecks auf Websites kommen ganz ohne Hacking aus. Eine Datei, die nie für die Öffentlichkeit bestimmt war, liegt im Web-Root, der Server liefert sie bereitwillig an jeden aus, der danach fragt, und sie enthält ein Datenbankpasswort, einen API-Schlüssel oder den kompletten Quellcode der Seite.

Die 3 üblichen Verdächtigen sind .env-Dateien mit Konfigurationsgeheimnissen, .git-Ordner mit der gesamten Repository-Historie und Sicherungskopien wie site.zip, db.sql oder config.php.bak. Der OWASP Web Security Testing Guide führt sie alle als typische Quellen offengelegter Zugangsdaten und offengelegten Quellcodes.

Mit curl prüfen Sie Ihre eigene Website darauf in wenigen Minuten.

Wie diese Dateien abrufbar werden

• .env-Dateien. Viele Frameworks lesen Geheimnisse aus einer .env-Datei im Projektordner. Ist das Document Root des Webservers der Projektordner statt seines Unterordners public, wird die Datei wie jede andere ausgeliefert.
• .git-Ordner. Wer per git clone oder git pull direkt im Web-Root deployt, hinterlässt das Verzeichnis .git neben der Website. Damit lassen sich der Quellcode und jeder frühere Commit rekonstruieren, einschließlich Geheimnissen, die längst „entfernt“ wurden.
• Backups und Dumps. Ein schnelles zip vor einem Update, ein db.sql-Export für eine Migration, eine Editor-Kopie wie index.php~ oder config.php.old. OWASP weist darauf hin, dass ein Backup eines Skripts als reiner Text ausgeliefert statt ausgeführt werden kann, womit sein Quellcode sichtbar wird.
• Überbleibsel von Werkzeugen. phpinfo.php, .htpasswd, .DS_Store, Terraform-State-Dateien und Logdateien tauchen auf die gleiche Weise auf.

Der gemeinsame Nenner: Es wird direkt auf dem Produktionsserver bearbeitet oder deployt, ohne einen Schritt, der entscheidet, was in den Web-Root gehört.

So prüfen Sie Ihre eigene Website

Rufen Sie die häufigsten Pfade ab und achten Sie auf Statuscode und Größe jeder Antwort:

for p in .env .git/HEAD .git/config backup.zip site.zip db.sql \
         dump.sql config.php.bak wp-config.php.bak phpinfo.php .DS_Store; do
  printf '%-22s ' "$p"
  curl -s -o /dev/null -w '%{http_code} %{size_download}\n' "https://yourcompany.com/$p"
done

Was die Ergebnisse bedeuten:

• 404 oder 403 für jeden Pfad ist das gewünschte Ergebnis.
• 200 mit echtem Inhalt ist ein Fund. Bei .git/HEAD sieht echter Inhalt aus wie ref: refs/heads/main. Bei .env sind es Zeilen der Form NAME=value.
• 200 mit Ihrer normalen Startseite oder einer eigenen Fehlerseite ist meist ein „Soft 404“. OWASP warnt, dass ein Treffer allein noch kein Fund ist: Öffnen Sie die Antwort und prüfen Sie, was sie tatsächlich enthält.

Wiederholen Sie die Prüfung für jeden Hostnamen, den Sie betreiben, auch für Staging- und alte Subdomains. Dort überleben solche Dateien am längsten, wie in unserem Artikel über vergessene Staging- und Testserver beschrieben. Webarchive können außerdem Kopien von Dateien enthalten, die früher abrufbar waren. Eine gerade entfernte Datei könnte also bereits gesehen worden sein.

Wurde ein Geheimnis offengelegt, zuerst rotieren

Das Löschen der Datei stoppt neue Downloads, aber Sie können nicht wissen, wer sie bereits kopiert hat. Behandeln Sie jedes Geheimnis in einer offengelegten Datei als kompromittiert:

1. Rotieren oder widerrufen Sie jedes Passwort, jeden API-Schlüssel und jedes Token aus der Datei. Die Anleitung von GitHub zum Entfernen sensibler Daten nennt dieselbe Reihenfolge: zuerst das Geheimnis widerrufen oder rotieren, dann die Historie bereinigen.
2. Entfernen Sie die Datei vom Server und aus jedem Backup-Ordner innerhalb des Web-Roots.
3. Prüfen Sie die Zugriffslogs auf Anfragen an diesen Pfad, um zu verstehen, ob und wann die Datei heruntergeladen wurde.
4. Prüfen Sie, was der Schlüssel erreichen konnte: Cloud-Konsolen, Zahlungsanbieter, Maildienste. Suchen Sie nach Aktivitäten, die Sie nicht erklären können.

Wurden Geheimnisse in ein Repository committet, hilft das Umschreiben der Historie (GitHub empfiehlt git-filter-repo) erst, wenn das Geheimnis selbst nicht mehr gültig ist.

So beugen Sie vor

• Lassen Sie das Document Root nur auf den öffentlichen Ordner zeigen, nie auf das Projektverzeichnis.
• Deployen Sie Build-Artefakte, keine Arbeitskopien. Eine CI-Pipeline, die nur die benötigten Dateien kopiert, hält .git und .env grundsätzlich fern.
• Blockieren Sie Dotfiles am Webserver, wie unten gezeigt.
• Halten Sie Geheimnisse möglichst aus Dateien heraus: Nutzen Sie die Umgebungsvariablen Ihrer Plattform oder einen Secrets Manager.
• Speichern Sie Backups oder Dumps nie im Web-Root. OWASP empfiehlt, Daten, Logs und Konfigurationsdateien dort abzulegen, wo der Webserver sie nicht ausliefern kann.
• Prüfen Sie nach jeder Infrastrukturänderung erneut, auch bei neuen Servern hinter einem Load Balancer.

Dotfiles zu blockieren (und dabei /.well-known/ zu erhalten, das die Zertifikatserneuerung braucht) sieht in nginx so aus:

location ~ /\.(?!well-known) {
    deny all;
}

Und so in einer Apache-Site-Konfiguration:

RedirectMatch 404 /\.(?!well-known)

Eine kurze Checkliste

• Führen Sie die curl-Schleife oben für jeden Ihrer Hostnamen aus.
• Bestätigen Sie jedes 200, indem Sie den Inhalt lesen.
• Rotieren Sie jedes Geheimnis, das jemals erreichbar war.
• Blockieren Sie Dotfiles und Backup-Endungen in der Webserver-Konfiguration.
• Stellen Sie Deployments auf eine Pipeline um, die nur gebaute Dateien ausliefert.

Wenn Sie schon in der Serverkonfiguration sind, ist das ein guter Moment, die HTTP-Sicherheitsheader zu ergänzen, die jede Unternehmenswebsite senden sollte.

Wie Datahorses hilft

Datahorses beobachtet Ihre Website von außen, so wie ein Angreifer sie betrachten würde, und meldet offene .git-, .env-, Backup- und Konfigurationsdateien, die Webarchive auf Ihren Domains erfasst haben. Wir dringen nicht in Ihre Systeme ein und benötigen keine Zugänge; Ihr Entwickler erhält genaue Schritte, um die Datei zu entfernen und das Abgeflossene zu rotieren. Siehe was wir überwachen und warum wir keine Zugänge brauchen.