Auch eine Entwicklungs-Website, die niemand kennt, braucht Schutz

«Niemand kennt die Adresse» ist kein Schutz, sondern ein Zufallsvorteil, der irgendwann endet. Automatisierte Scanner testen fortlaufend ganze IP-Bereiche und Domain-Muster durch und finden Test- und Entwicklungsseiten oft innerhalb weniger Tage – unabhängig davon, ob jemand den Link je öffentlich geteilt hat. Eine unveröffentlichte Test- oder Entwicklungsseite muss darum genauso abgesichert werden wie die Hauptseite.

Wie ein Bot eine Seite findet, die niemand verlinkt hat

Entwicklungsseiten heissen fast immer nach demselben Muster: dev.firma.ch, staging.firma.ch, test.firma.ch. Scanner probieren solche Präfixe systematisch gegen bekannte Domains durch, unabhängig von Google oder Suchmaschinen. Ist die Subdomain per DNS aufgelöst und ohne Passwortschutz erreichbar, taucht sie irgendwann in einer solchen Liste auf – meist ohne dass am eigentlichen Betrieb der Website etwas Auffälliges passiert.

Es geht aber oft noch schneller, und dieser Weg wird regelmässig übersehen: Jedes öffentlich anerkannte TLS-Zertifikat wird öffentlich protokolliert. Sobald ihr für dev.firma.ch ein Zertifikat bezieht – etwa automatisch über Let’s Encrypt –, erscheint der vollständige Hostname kurz darauf in den öffentlich durchsuchbaren Certificate-Transparency-Protokollen. Jeder kann sie abfragen. Die Subdomain ist damit bekannt, bevor der erste Mensch sie je aufgerufen hat.

Das ist kein Fehler des Systems, sondern seine Funktion: Certificate Transparency existiert, damit gefälschte Zertifikate auffallen. Nur ist die Nebenwirkung, dass «geheime» Hostnamen keine Geheimnisse sind.

Warum ausgerechnet die Formulare das Ziel sind

Der Bot wollte keine echten Anfragen stellen. Die meisten Felder enthielten Zufallszeichen oder generische Test-Adressen – typisch für automatisierte Prüfungen, ob sich über ein Formularfeld die Datenbank manipulieren lässt (sogenannte SQL-Injection-Versuche). Formulare sind für solche Scanner attraktiv, weil sie eine der wenigen Stellen einer Website sind, an denen Eingaben tatsächlich verarbeitet und gespeichert werden – anders als eine reine Textseite.

Ein konkreter Fall aus der Praxis: Eine Firmenwebsite mit Kontakt-, Bewerbungs- und Serviceformularen betrieb parallel eine öffentlich erreichbare Entwicklungsseite mit identischem Code – auch identischen Formularen. In einer einzigen Nacht sendete ein automatisierter Bot rund 16’000 Formular-Absendungen an diese Entwicklungsseite, im Schnitt etwa eine pro Sekunde, über vier Stunden ohne Unterbruch. Die Hauptseite blieb im selben Zeitraum praktisch unberührt.

Was der Bot erreichte – und was nicht

Der bestehende Spam-Filter blockierte rund zwei Drittel der Anfragen automatisch. Das verbleibende Drittel – knapp 5’400 Mails – landete trotzdem im Postfach der zuständigen Stelle. Kein einziger Datensatz ging dabei verloren, keine Datenbank wurde kompromittiert: Die Schutzmechanismen, die für die Hauptseite gedacht waren, hielten. Der Schaden blieb auf ein überfülltes Postfach und kurzzeitige Serverlast beschränkt.

Das ist die eigentliche Lehre: Die Entwicklungsseite war nicht ungeschützt, weil ihre Firewall schwächer war – sie war ungeschützt, weil niemand daran gedacht hatte, dass sie überhaupt öffentlich erreichbar sein durfte. «Wird schon niemand finden» ist kein Sicherheitskonzept, sondern eine Wette, die ein Scanner-Netzwerk irgendwann gewinnt.

Was diesen Vorfall von einem echten Sicherheitsleck unterscheidet:

• Kein Zugriff auf echte Kundendaten – die Formulare wurden durchprobiert, nicht die Datenbank ausgelesen.
• Keine Serverkompromittierung – der Bot blieb auf der Ebene eines normalen Website-Besuchers, nur in absurder Frequenz.
• Kein gezielter Angriff auf die Firma – die IP-Adresse gehörte zu einem Rechenzentrum, das typischerweise für Massen-Scans gemietet wird; die Auswahl der Zieladresse war generisch, nicht persönlich.

Eine Entwicklungsseite ohne Passwortschutz ist keine unsichtbare Seite – sie ist eine Seite, die noch niemand gefunden hat.

Welche Massnahme wovor schützt – und wovor nicht

Nicht jede naheliegende Massnahme wirkt, und zwei davon sind sogar kontraproduktiv:

Wie ihr eure Entwicklungsseite prüft und absichert

1. Herausfinden, welche Subdomains überhaupt existieren. Fragt die Certificate-Transparency-Protokolle für eure Domain ab (etwa über crt.sh). Dort steht jeder Hostname, für den je ein Zertifikat ausgestellt wurde – oft mehr, als im Haus bekannt ist. Vergessene Staging-Umgebungen früherer Agenturen tauchen genau hier auf.
2. Jede gefundene Adresse im privaten Fenster öffnen. Erscheint die Seite ohne Login, ist sie öffentlich – unabhängig davon, ob sie irgendwo verlinkt ist.
3. Passwortschutz auf Serverebene setzen, nicht in der Anwendung. Bei Apache eine .htaccess mit AuthType Basic und einer .htpasswd-Datei; bei Nginx auth_basic. Er greift, bevor PHP, WordPress oder ein Formular überhaupt geladen werden – und schützt damit auch vor Lücken, die ihr noch gar nicht kennt.
4. Prüfen, ob der Schutz wirklich greift, und zwar nicht nur auf der Startseite: Ruft eine Unterseite, das Formular-Ziel und die Admin-Anmeldung direkt auf. Ein Schutz, der nur den Einstieg absichert, ist keiner.
5. Die Spam-Abwehr gleich scharf stellen wie auf der Hauptseite – nicht laxer, «weil es ja nur zum Testen ist». Und eine Rate-Begrenzung setzen, die auffällig viele Absendungen aus derselben Quelle stoppt.

Zwei Fallstricke, die den Schutz aushebeln:

• Basic Auth blockiert auch eure Werkzeuge. Webhooks, Deployment-Skripte, Zahlungs-Rückmeldungen und Vorschau-Funktionen scheitern plötzlich still. Wer das nicht bedenkt, deaktiviert den Schutz nach dem dritten Ärger wieder. Nehmt gezielt einzelne Pfade aus, statt den Schutz ganz abzuschalten.
• Die Seite ist über die IP-Adresse weiterhin erreichbar. Wer den Schutz nur an den Hostnamen hängt, lässt die Tür offen, wenn der Server direkt über seine IP angesprochen wird. Der Schutz gehört an den Server, nicht an den Namen.