Scanner für offene Panels

Wie diese Prüfung funktioniert

Scanaris fordert eine Liste von Pfaden an, die zu Panels und Debug-Werkzeugen gehören, die in Produktion nie antworten sollten, und prüft, dass die Antwort wirklich die des Werkzeugs ist und nicht die generische Seite deiner Website. Die Pfade und ihr Schweregrad: /actuator/health von Spring Boot (hoch), /actuator/env und /actuator/heapdump (kritisch: Umgebungsvariablen und Speicherabbild), /telescope/requests von Laravel Telescope (hoch), /_ignition/health-check von Laravel Ignition im Debug-Modus (kritisch, weil verwundbare Versionen Codeausführung erlaubten), /_profiler von Symfony (hoch), /.vscode/sftp.json mit Deploy-Zugangsdaten (kritisch), /server-status von Apache (mittel) und /phpmyadmin/ (hoch).

Warum das wichtig ist

Diese Werkzeuge existieren, um dem, der die Anwendung entwickelt, ihr Innenleben zu zeigen: Konfiguration, Umgebungsvariablen mit Passwörtern, jüngste Anfragen mit ihren Parametern, vollständige Fehler-Traces, Inhalt des Prozessspeichers. In der Entwicklung sind sie wertvoll; in Produktion, offen im Internet, sind sie eine Tür mit steckendem Schlüssel. Ein erreichbares /actuator/env enthält oft den Verbindungsstring zur Datenbank. Ein öffentliches phpMyAdmin ist ein Einstiegspunkt, um rund um die Uhr Passwörter gegen deine Datenbank zu testen.

Warum das passiert

Weil dieselbe Konfiguration für Entwicklung und Produktion dient. Der Debug-Modus von Laravel (APP_DEBUG=true), die in alten Spring-Versionen standardmäßig exponierten Actuator-Endpunkte, der Symfony-Profiler mit APP_ENV=dev, ein phpMyAdmin, das „kurz zum Reinschauen in die Datenbank" installiert und nie entfernt wurde. KI-Werkzeuge, die das Projekt erzeugen, unterscheiden selten zwischen Umgebungen, und das Deployment erbt die Entwicklungskonfiguration.

So behebst du es

• Laravel: APP_DEBUG=false und APP_ENV=production in der .env der Produktion. Telescope nur lokal (TELESCOPE_ENABLED=false oder das Autorisierungs-Gate). Aktualisiere Ignition auf eine Version ohne die Schwachstelle.
• Spring Boot: höchstens management.endpoints.web.exposure.include=health, ohne env und heapdump, und mit Security vor /actuator. Noch besser: Exponiere den Actuator auf einem separaten Management-Port, der nicht ins Internet geht.
• Symfony: APP_ENV=prod und APP_DEBUG=0; der Profiler wird nur in dev registriert.
• phpMyAdmin: deinstalliere es vom öffentlichen Server. Wenn du es brauchst, greif per SSH-Tunnel darauf zu oder beschränke es per IP mit zusätzlicher Authentifizierung.
• Apache server-status: Require ip 127.0.0.1 in der Direktive Location /server-status, oder deaktiviere das Modul.
• Editor-Dateien wie .vscode/sftp.json: Sie dürfen nie deployt werden. Füge .vscode/ zur .gitignore hinzu und, falls sie veröffentlicht wurde, ändere das enthaltene Passwort.

Prüf, ob es behoben ist

for p in actuator/health actuator/env telescope/requests _ignition/health-check _profiler .vscode/sftp.json server-status phpmyadmin/; do
  printf "%-26s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://deinedomain.de/$p"
done

Erwartet: 404, 403 oder 401 überall. Ein 200 ist nur akzeptabel, wenn das Zurückgegebene deine generische Seite ist und nicht das Werkzeug.

Häufige Fragen

Mein Panel verlangt ein Passwort. Ist das trotzdem ein Befund?

Scanaris prüft den Inhalt, also wird ein durch Authentifizierung geschütztes Panel, das 401 zurückgibt, nicht gemeldet. Trotzdem ist ein phpMyAdmin mit Login ein Brute-Force-Ziel; besser außerhalb des Internets.

Und /actuator/health? Es sagt nur „UP".

Es bestätigt die Technologie und die Spring-Version, die du nutzt, und deutet meist darauf hin, dass die anderen Endpunkte auch exponiert sind. Wenn du einen öffentlichen Health Check für deinen Load Balancer brauchst, erstell eine eigene minimale Route, statt den Actuator zu öffnen.

Ich nutze Next.js oder Nuxt. Betrifft mich das?

Diese konkreten Pfade nicht, aber das Prinzip schon: Debug- oder Seed-API-Routen (/api/debug, /api/seed), die die KI zum Testen anlegt, müssen vor dem Deployment verschwinden.