Debugmodus in der Produktion eingeschaltet

Der Debugmodus ist darauf ausgelegt, so viel wie möglich preiszugeben: Genau darin besteht sein Zweck während der Entwicklung. Bleibt diese Einstellung in der Produktion eingeschaltet, erledigt sie diese Aufgabe unverändert gut, nur für ein anderes Publikum. In diesem Artikel lesen Sie, was dabei sichtbar wird und warum manche Entwicklungswerkzeuge nicht nur Informationen preisgeben, sondern unmittelbaren Zugriff gewähren.

Was ist Debugmodus?

Debugmodus ist der Zustand, in dem ein Framework oder eine Anwendung so viele Informationen wie möglich darüber zeigt, was intern geschieht. Bei einem Fehler erscheint keine ordentliche Meldung, sondern eine vollständige Erläuterung: der Stack-Trace mit Dateipfaden und Zeilennummern, die Werte von Variablen, die ausgeführten Datenbankabfragen, die geladene Konfiguration und mitunter die vollständigen Umgebungsvariablen.

Daneben gibt es Entwicklungswerkzeuge, die dauerhaft mitlaufen: Profiler, Debugleisten, Fehlerkonsolen. Diese zeigen nicht nur, was schiefging, sondern alles, was geschah, auch bei einer erfolgreichen Anfrage. Sie sind für eine Umgebung gedacht, in der nur der Entwickler Zugang hat.

Der Gegensatz zur beabsichtigten Lage ist groß. In der Produktion sollte ein Fehler eine neutrale Meldung mit einer Vorgangsnummer ergeben. Im Debugmodus ergibt derselbe Fehler eine ausführliche Beschreibung Ihres Systems, für jeden, der danach fragt.

Was macht der Debugmodus sichtbar?

Verwundbar:

// In der Konfigurationsdatei der Produktionsumgebung
APP_ENV=production
APP_DEBUG=true

Ein einziger falsch gesetzter Wert. Eine Anfrage, die einen Fehler auslöst, liefert nun eine Seite mit unter anderem folgendem Inhalt:

UnexpectedValueException in /var/www/portal/src/Rechnung/Repository.php:88

Umgebungsvariablen:
  DB_HOST=10.0.4.12
  DB_USERNAME=portal_prod
  DB_PASSWORD=Xk29!vRp2mQz
  MAIL_PASSWORD=cf83e1357eefb8bd
  APP_KEY=base64:9c2f81ad4e7b3f5c...

Das ist kein Informationsleck im üblichen Sinn mehr. Das Datenbankpasswort steht auf dem Bildschirm; ist die Datenbank von außen erreichbar, bedeutet das unmittelbaren Zugriff auf sämtliche Daten. Der Anwendungsschlüssel ist noch schwerwiegender: Damit lassen sich Session-Cookies fälschen, und bei Frameworks, die Objekte in Cookies ablegen, kann das zur Codeausführung auf dem Server führen.

Bei einem Profiler kommt noch etwas hinzu. Manche Werkzeuge bieten eine eingebaute Konsole oder eine Route, über die sich beliebige Ausdrücke auswerten lassen. Ist diese ohne Authentifizierung erreichbar, ist der Schritt vom Informationsleck zur vollständigen Übernahme bereits getan.

Sicher:

APP_ENV=production
APP_DEBUG=false

// Die Anwendung verweigert den Start bei einer unsicheren Kombination
if (env('APP_ENV') === 'production' && env('APP_DEBUG') === true) {
    throw new RuntimeException('Debugmodus ist in der Produktion nicht zulässig.');
}

Die zweite Maßnahme ist die wichtigere. Eine Einstellung, die nur deshalb richtig steht, weil jemand daran gedacht hat, steht früher oder später falsch. Eine Anwendung, die bei einer unsicheren Kombination den Start verweigert, macht den Fehler unmöglich statt unwahrscheinlich. Entfernen Sie zusätzlich Entwicklungspakete vollständig aus dem Produktions-Build, damit ein Profiler nicht nur abgeschaltet, sondern gar nicht vorhanden ist.

Welche Auswirkungen hat Debugmodus in der Produktion?

Der Schweregrad ist hoch bis kritisch, und das unterscheidet diesen Befund von gewöhnlichen Informationslecks. Der Grund liegt darin, dass die preisgegebenen Angaben meist Geheimnisse enthalten und nicht nur Strukturinformationen.

Der schwerwiegendste Weg führt über den Anwendungsschlüssel. Bei vielen Frameworks werden Sitzungen und Cookies damit signiert oder verschlüsselt. Wer den Schlüssel besitzt, kann eine gültige Sitzung für jeden Nutzer erzeugen, einschließlich Administratoren, ohne je ein Passwort kennen zu müssen. Bei Frameworks, die serialisierte Objekte in Cookies ablegen, kann das bis zur Ausführung von Code auf dem Server reichen.

Darüber hinaus liegen Datenbankzugangsdaten, Schlüssel für Zahlungs- und E-Mail-Dienste sowie interne Netzwerkadressen offen. Letztere sind für den nächsten Schritt wertvoll: Sie verraten einem Angreifer, welche Systeme hinter der Anwendung laufen und worauf er seine Aufmerksamkeit richten sollte.

Besonders unangenehm an diesem Befund ist, dass sein Auffinden keinerlei Fertigkeit erfordert. Es wird großflächig automatisiert nach Anwendungen mit aktivem Debugmodus gesucht, gerade weil der Ertrag so hoch ist.

Wie spürt man Debugmodus in der Produktion auf?

Ein Tester löst gezielt Fehler aus, einen ungültigen Parameterwert, eine nicht vorhandene Route, eine fehlerhaft aufgebaute Anfrage, und beurteilt, ob die Antwort mehr zeigt als eine neutrale Meldung. Ein Stack-Trace mit Dateipfaden ist das deutlichste Signal.

Zusätzlich wird nach den bekannten Pfaden von Entwicklungswerkzeugen gesucht: Profiler-Routen, Debugleisten, Statusseiten und Routen, die die Konfiguration oder die geladenen Module zeigen. Diese stehen häufig unter einer vorhersehbaren Adresse und sind mit einer gezielten Prüfung schnell zu finden. Auch feinere Hinweise erhalten Aufmerksamkeit: ein Antwortheader, der den Debugzustand verrät, ein HTML-Kommentar mit der Ausführungszeit oder eine Fehlerseite, die nur im Entwicklungsmodus erscheint. Abnahme- und Testumgebungen erhalten besondere Aufmerksamkeit, denn sie sind häufig aus dem Internet erreichbar und laufen nahezu immer im Debugmodus mit produktionsähnlichen Daten. AssistSec bezieht diese Umgebungen standardmäßig in die Erkundung ein, denn in der Praxis erweisen sie sich häufiger als Eingang als die Produktionsumgebung selbst.

Wie verhindert man Debugmodus in der Produktion?

• Schalten Sie den Debugmodus in jeder aus dem Internet erreichbaren Umgebung ausdrücklich ab.
• Lassen Sie die Anwendung den Start verweigern, wenn Debugmodus und Produktion zugleich eingestellt sind.
• Entfernen Sie Profiler und andere Entwicklungspakete vollständig aus dem Produktions-Build.
• Halten Sie Geheimnisse aus der Konfiguration heraus, die bei einem Fehler angezeigt werden kann, etwa in einem Schlüsseltresor.
• Rotieren Sie alle Geheimnisse, wenn der Debugmodus unbeabsichtigt eingeschaltet war.
• Schirmen Sie Test- und Abnahmeumgebungen mit Netzwerkbeschränkungen oder Authentifizierung ab.
• Verwenden Sie strukturierte Protokollierung mit Vorgangsnummern statt Informationen in der Antwort.
• Prüfen Sie die Einstellung bei jeder Auslieferung automatisch, damit eine manuelle Änderung nicht bestehen bleibt.
• Sperren Sie bekannte Debug- und Profilerpfade in Ihrem Webserver als Auffangnetz.