Wie konnte das nur passieren?

Das Passwort habe ich umgehend geändert. Das Risiko ist überschaubar. Der Datenbanknutzer hatte nur Zugriffsrechte auf diese eine Datenbank, und darin war nichts geändert. Der Angreifer hätte zwar die Kontrolle über den Inhalt meiner Webseite erlangen können - es existiert eine Installation von PhpMyAdmin, die auch relativ leicht zu finden ist -, aber mehr vermutlich nicht. Es gibt keine direkte Möglichkeit, durch die Kontrolle über die Datenbank Code auf dem Server auszuführen. Diese Möglichkeit besteht nur, wenn ein Datenbanknutzer erweiterte Rechte hat (etwa die "FILE"-Berechtigung), aber das war nicht der Fall.

Passiert ist Folgendes: Aus komplett anderen Gründen war der MySQL-Datenbankserver abgestürzt und für kurze Zeit offline. Das führte dazu, dass beim Verbindungsversuch zur Datenbank ein Fehler auftrat. Es müssen ein paar Dinge zusammenkommen, damit dieser Fehler auftritt und ein Passwort enthält.

PHP besitzt eine Option display_errors, mit der konfiguriert werden kann, ob Fehlermeldungen direkt angezeigt werden. Die PHP-Dokumentation empfiehlt, diese Option auf Produktivsystemen zu deaktivieren, verschweigt aber die erheblichen Risiken, die damit einhergehen. Allerdings ist display_errors standardmäßig aktiviert, wenn man die Option in der PHP-Konfiurationsdatei überhaupt nicht setzt. Das steht übrigens nicht in der Dokumentation.

Display-Errors war bewusst aktiv

Es war kein Versehen, dass display_errors aktiviert war. Ich hatte mich vor längerer Zeit bewusst dafür entschieden. Ursprünglich war die Option auf dem entsprechenden Server global deaktiviert. Ich hatte allerdings bei einem Test einer neueren PHP-Version vor einiger Zeit gemerkt, dass mehrere meiner PHP-Skripte Fehler enthielten, die durch das Abschalten der display_errors-Option unbemerkt blieben. Um das zu verhindern, hielt ich es für sinnvoller, die Anzeigen von Fehlermeldungen standardmäßig zu aktivieren. Im Rückblick war das keine gute Idee.

Eine weitere Besonderheit hier ist, dass die Fehlermeldung einen Stack Trace enthielt. Nur dadurch wurde das Passwort sichtbar. Nicht alle Fehlermeldungen von PHP enthalten Stack Traces. Für Datenbankzugriffe verwendet die Seite die objektorientierte PDO-Erweiterung von PHP (PHP Database Object). Im Fall eines Verbindungsfehlers erzeugt diese eine Exception. Exceptions können mit den Befehlen try und catch abgefangen werden. Wenn man Exceptions jedoch unbehandelt lässt, werden die Fehlermeldungen mit Stack Trace ausgegeben. Fairerweise sei hier gesagt, dass die PDO-Dokumentation eine deutliche Warnung vor diesem Szenario enthält.

MySQL produziert harmlose Fehlermeldungen

Ungewöhnlich ist hier die uneinheitliche Behandlung von Fehlern durch PHP. Als Alternative zu PDO gibt es in PHP für MySQL-Verbindungen die mysqli-API. Die verwendet keine Exceptions und die Fehlermeldungen enthalten weder Stack Traces noch Passwörter. Das erscheint mir insofern bemerkenswert, als ich in der Vergangenheit häufig Nutzern empfohlen habe, PDO mit Prepared Statements zu verwenden. Die mysqli-API unterstützt jedoch ebenfalls Prepared Statements und ist daher möglicherweise die sicherere Alternative.