Vergessene Staging- und Testserver: der Teil, den niemand beobachtet

Ein vergessener Staging- oder Testserver ist eine Kopie Ihrer Website oder App, die für die Entwicklung aufgesetzt und dann im Internet laufen gelassen wurde. Er liegt meist unter einem Namen wie staging.yourcompany.com, dev.yourcompany.com oder test2.yourcompany.com, niemand schaut mehr nach ihm, und oft läuft dort älterer Code mit schwächeren Einstellungen als in der Produktion.

Diese Server sind wichtig, weil sie Teil der Internetpräsenz Ihres Unternehmens sind, auch wenn niemand sie so behandelt. Sie bekommen nicht dieselben Updates, Logins und dasselbe Monitoring wie die Hauptseite, teilen aber häufig dieselben Datenbankkopien, API-Schlüssel und Admin-Konten.

Die gute Nachricht: Sie sind leicht zu finden, und ist das geschehen, ist die Lösung meist einfach. Dieser Artikel zeigt, wie Sie danach suchen und was Sie mit jedem einzelnen tun.

Warum Staging-Server vergessen werden

Ein Staging-Server entsteht aus gutem Grund: um ein Release zu testen, bevor Kunden es sehen. Dann geht das Release live, der Entwickler wechselt zu einem anderen Projekt oder der Vertrag mit der Agentur endet, und der Server läuft weiter, weil das Abschalten nie auf jemandes Aufgabenliste stand. Typische Muster:

• Eine vollständige Kopie der Produktion, inklusive eines aktuellen Datenbank-Dumps, damit Tests realistisch wirken.
• Eingeschalteter Debug-Modus, der Stacktraces, Konfigurationswerte oder Framework-Details anzeigt.
• Standard- oder gemeinsam genutzte Admin-Passwörter, die „nur zum Testen“ waren.
• Alte Versionen von CMS, Plugins oder Bibliotheken, die in der Produktion längst aktualisiert wurden.
• Kein HTTPS oder ein Zertifikat, das vor Monaten abgelaufen ist.
• Nie blockierte Indexierung durch Suchmaschinen, sodass die Testseite neben der echten erscheint.

Nichts davon ist für sich genommen dramatisch. Zusammen ergibt es einen Host unter Ihrer eigenen Domain, der schwächer ist als alles um ihn herum.

Wie diese Server sichtbar werden

Sie müssen keinen Link veröffentlichen, damit ein Staging-Host gefunden wird. 3 übliche Wege:

1. Certificate Transparency. Wird ein allgemein vertrauenswürdiges Zertifikat für staging.yourcompany.com ausgestellt, wird der Name in offene Logs geschrieben (das Protokoll ist in RFC 9162 beschrieben). Diese Logs kann jeder durchsuchen, wie in Certificate Transparency Logs erklärt beschrieben.
2. DNS-Einträge. Ein Eintrag, der noch auf den Server zeigt, macht ihn über den Namen erreichbar, und leicht zu erratende Namen wie dev, test und beta werden zuerst ausprobiert.
3. Suchmaschinen und Archive. Eine Testseite ohne Indexierungsregeln kann in Suchergebnissen auftauchen, und alte Seiten bleiben in Webarchiven erhalten.

So finden Sie Ihre eigenen vergessenen Server

Beginnen Sie mit den Namen und prüfen Sie dann jeden einzelnen.

1. Durchsuchen Sie crt.sh nach %.yourcompany.com und sammeln Sie jeden Hostnamen.
2. Gehen Sie Ihre DNS-Zone nach Namen wie dev, stage, staging, test, uat, beta, old, demo, preview durch.
3. Lösen Sie jeden Namen auf und prüfen Sie die Antwort:

dig +short staging.yourcompany.com
curl -sI https://staging.yourcompany.com

1. Öffnen Sie jeden Host im Browser und fragen Sie: Zeigt er echte Kundendaten, ein Login-Formular, eine Debug-Seite, eine Standard-Serverseite oder eine Fehlermeldung einer Hosting-Plattform?
2. Suchen Sie nach Dateien, die nie ausgeliefert werden sollten. Der OWASP-Testleitfaden behandelt das in WSTG-CONF-04 und weist darauf hin, dass Backup-Dateien eher als reiner Text ausgeliefert als ausgeführt werden. Unser Artikel über offene .env-, .git- und Backup-Dateien nennt die üblichen Namen.

Zeigt ein Name auf eine Hosting-Plattform, die eine Seite wie „no such app“ oder „bucket not found“ anzeigt, behandeln Sie das als dringend: Das ist die klassische Ausgangslage für einen Subdomain Takeover.

Was Sie mit jedem Server tun

Wählen Sie für jeden Staging- oder Testhost eines von 3 Ergebnissen.

Entfernen. Kann niemand Verantwortlichen und Zweck nennen, schalten Sie den Server ab und löschen den DNS-Eintrag. Löschen Sie den Eintrag nach dem Server, nicht vorher, und lassen Sie nie einen CNAME auf einen Dienst zeigen, für den Sie nicht mehr bezahlen.

Einschränken. Braucht das Team ihn noch, stellen Sie ihn hinter eine Authentifizierung oder eine IP-Allowlist. HTTP Basic Authentication ist schnell eingerichtet, doch MDN weist darauf hin, dass sie nur über HTTPS genutzt werden darf, weil Zugangsdaten lediglich base64-kodiert sind. Ein VPN oder ein Identity-Aware Proxy ist langfristig die bessere Wahl.

Bereinigen. Auf Staging gehören keine echten Kundendaten. Nutzen Sie generierte oder maskierte Daten, separate API-Schlüssel mit eingeschränkten Rechten und schalten Sie Debug-Ausgaben ab.

Suchmaschinen fernzuhalten ist sinnvoll, aber kein Schutz. Google dokumentiert noindex als Weg, Seiten aus den Ergebnissen herauszuhalten, über <meta name="robots" content="noindex"> oder einen X-Robots-Tag-Header (Google Search Central). Die Seite bleibt für jeden erreichbar, der die Adresse kennt.

X-Robots-Tag: noindex

Eine kurze Checkliste

• Jeder Nicht-Produktionshost hat einen benannten Verantwortlichen und ein Enddatum.
• Keine echten Kundendaten auf Staging.
• Staging verlangt einen Login oder liegt hinter einem VPN.
• Debug-Modus aus, separate Schlüssel, keine gemeinsamen Admin-Passwörter.
• Gültiges Zertifikat, oder der Host wird entfernt.
• DNS-Einträge werden zusammen mit dem Server gelöscht.
• Die Liste wird nach jedem Projektende geprüft, nicht einmal im Jahr.

Wo Datahorses ins Bild passt

Datahorses beobachtet Ihr Unternehmen jeden Tag von außen, darunter neue Hostnamen unter Ihren Domains, vergessene Subdomains und Testserver sowie dort abrufbare Dateien. Jeder Fund kommt mit genauen Schritten für Ihren Entwickler, und wir dringen nicht in Ihre Systeme ein und benötigen keine Zugänge. Siehe was wir überwachen und was passiert, wenn wir etwas finden.