Scanner für herunterladbare Backups

Wie diese Prüfung funktioniert

Scanaris fordert neun Dateinamen an, die Leute immer wieder verwenden, um Backups im Root der Website abzulegen: backup.zip, backup.tar.gz, website.zip, www.zip, public_html.zip, site.zip, database.sql, dump.sql und db.sql. Für jeden prüft er, dass die Antwort eine echte Datei ist und nicht die generische Seite deiner Website: Er schaut auf den Content-Type und, bei SQL-Dumps, ob der Text nach SQL aussieht. Alle Befunde haben kritischen Schweregrad, weil so eine Datei entweder den vollständigen Code der Seite oder die ganze Datenbank enthält.

Warum das wichtig ist

Eine erreichbare backup.zip ist dein komplettes Projekt: Code, Konfiguration, die Schlüssel, die in den Dateien herumlagen, und oft eine Kopie der Datenbank obendrein. Eine dump.sql ist die Datenbank wie sie ist: Nutzer, E-Mails, gehashte Passwörter (in aller Ruhe angreifbar), Bestellungen, Nachrichten. Keine Technik nötig: Es ist ein Download. Und automatische Scanner probieren genau diese Namen gegen jede Domain, die sie finden, also ist „niemand kennt die URL" kein Schutz.

Warum das passiert

Aus Bequemlichkeit im falschen Moment: Vor einer Migration oder einem Update wird der Ordner der Seite „zur Sicherheit" komprimiert und dort liegen gelassen. Oder ein Backup-Plugin schreibt in einen öffentlichen Ordner. Oder ein Datenbankexport wird neben dem Code gespeichert, um ihn jemandem weiterzugeben. Auf einem Server, der das Projekt-Root ausliefert, ist jede Datei, die dort landet, sofort öffentlich.

So behebst du es

• Lösch die Datei jetzt und handle so, als wäre sie heruntergeladen worden: Rotiere alle Schlüssel und Passwörter, die sie enthielt, und wenn personenbezogene Daten drin waren, prüf die Meldepflicht.
• Verschieb Backups aus dem öffentlichen Verzeichnis. Backups gehören in einen separaten Speicher (einen privaten Bucket, einen anderen Server), nie in einen vom Webserver ausgelieferten Ordner.
• Konfiguriere das Backup-Tool so, dass es außerhalb des Web-Roots schreibt. WordPress-Plugins erlauben meist, den Ordner zu wählen oder zu einem externen Dienst zu senden.
• Blockiere die Erweiterungen serverseitig als zweite Barriere. In nginx: location ~* \.(zip|tar|gz|sql|bak)$ { deny all; }. In Apache ein entsprechendes FilesMatch mit Require all denied. Wenn du legitim komprimierte Downloads anbietest, beschränke sie auf einen bestimmten Ordner.
• Prüf die Zugriffsprotokolle auf 200-Anfragen an diese Namen: Sie verraten dir, ob schon jemand da war.

Prüf, ob es behoben ist

for p in backup.zip backup.tar.gz website.zip www.zip public_html.zip site.zip database.sql dump.sql db.sql; do
  printf "%-18s " "$p"; curl -s -o /dev/null -w "%{http_code} %{content_type}\n" "https://deinedomain.de/$p"
done

Erwartet: 404 oder 403. Ein 200 mit text/html bei einer Single-Page-App ist ihr generisches HTML; ein 200 mit application/zip, application/octet-stream oder text/plain ist die echte Datei.

Häufige Fragen

Mein Backup hat einen Namen, den niemand erraten würde.

Angriffstools probieren Tausende Namen und Kombinationen mit Domain, Datum und Wörtern wie „old" oder „bak". Ein ungewöhnlicher Name senkt das Risiko, beseitigt es aber nicht; die Lösung ist, dass die Datei nicht in einem öffentlichen Ordner liegt.

Und wenn die Datei passwortgeschützt ist?

Ein ZIP mit Passwort lässt sich genauso herunterladen und auf dem Rechner des Angreifers ohne Versuchslimit knacken. Es bleibt ein kritischer Befund.

Die Prüfung schaut nur ins Root. Was ist mit Unterordnern?

Richtig, diese neun Namen werden im Root getestet. Offene Verzeichnisauflistungen, die eine andere Prüfung misst, sind der übliche Weg, Backups in Unterordnern zu finden; sie zu schließen und die Erweiterungen zu blockieren deckt den Rest ab.