Fehleranzeige trotz Debug-Mode false

Die Zeiten ändern sich.

Dieser Beitrag scheint älter als 2 Jahre zu sein – eine lange Zeit im Internet. Der Inhalt ist vielleicht veraltet ...

Fehlermeldungen sollten in einer Live-Website niemals ausgegeben werden. WordPress setzt in der wichtigen Konfigurationsdatei wp-config.php den Debug-Modus auch auf „Aus“ (false). Trotzdem erscheinen manchmal Fehlermeldungen. Wieso ist das so? Und was haben die Hoster damit zu tun?

Dazu müssen wir ein wenig ausholen.

Fangen wir damit an zu erklären, warum das überhaupt ein Problem ist. Ein mögliches Datenleck, dass hierbei entsteht, nennt sich „Full Path Disclosure“. Die Fehlermeldung enthält den Pfad zur betroffenen Datei und dieser Pfad gibt einem möglichen Angreifer Informationen.

Manche Hoster nutzen zum Beispiel die Kundennummer im Pfad. Ist diese nun bekannt, ist der Angreifer schon einen Schritt weiter. Auf der Fehlermeldungsseite kann dann zusätzlich auch noch die PHP-Version ausgegeben werden und falls diese veraltet ist und Lücken enthält, hat der Angreifer nun die Information für einen weiteren möglichen Angriffsvektor.

Wer es selbst mal testen möchte, der ruft mal /wp-includes/rss.php auf seiner Website auf und schaut, was ausgegeben wird. Im besten Fall nur eine weiße Seite, im schlechteren Fall eine Fehlermeldung inklusive Pfad auf dem Server, wie das hier:

Fatal error: Uncaught Error: Call to undefined function _deprecated_file() in /kunden/123456/webseiten/example.org/wp-includes/rss.php:19 Stack trace: #0 {main} thrown in /kunden/123456/webseiten/example.org/wp-includes/rss.php on line 19

(Leider wird das wpcheck-Tool von Sergej Müller nicht mehr weiter entwickelt. Damit konnte das auf der Kommandozeile schnell getestet werden. Einen Artikel dazu gibt es auch hier im Blog.)

WordPress empfiehlt zwar explizit Fehlermeldungen nicht auszugeben auf einer Live-Website. Aber wie kann ein Laie das wissen? Eine Datei wie oben beschrieben aufzurufen macht ja niemand einfach so.

Und der Debug-Modus steht standardmäßig doch auf false in der Konfigurationsdatei:

define( 'WP_DEBUG', false );

Warum wird dann trotzdem eine Fehlermeldung ausgegeben?

Weil diese PHP-Einstellung auf Serverebene schon passiert und WordPress sich entschieden hat, diese nicht zu ändern. In Ticket #11987 wird das mal etwas diskutiert und erklärt. Auch die Inline-Dokumentation erklärt das Ganze, aber welcher Laie liest Inline-Dokumentation? Und selbst wenn es gelesen wird – beim ersten Mal lesen habe ich nicht die Konsequenz sofort verstanden.

Die Zusammenfassung für uns ist: Wenn die Anzeige von Fehler auf dem Server aktiviert ist, so wird keine Einstellung in WordPress dies ändern. Es muss auf Server/PHP-Ebene deaktiviert werden.

Das Problem wurd auch schon mehrfach bei Trac angesprochen von mir. #35835 fixte ein Vorkommen des Problems im Core, aber löste das Problem nicht generell. Da habe ich das erste Mal darauf hingewiesen, dass wir im Site-Health-Feature einen Test dazu einbauen sollten. Nachdem das Ticket geschlossen wurde, gab es #51806 für weitere Vorkommen des Problems im Core. Auch hier schlug ich vor, einen Check für Site Health einzubauen oder alternativ die Fehleranzeige standardmäßig zu deaktivieren. Leider hat das Ticket keinen geplanten Milestone mehr.

Einen weiteren Versuch habe ich dann in #52652 gestartet. Hier habe ich explizit nur vorgeschlagen einen Test in Site Health einzubauen. Das Ganze benötigt allerdings noch Dokumentation. Geplant ist dafür die Hardening WordPress Webseite.

Wie deaktiviere ich denn nun die Anzeige von Fehlern? Ein Weg ist die .htaccess, denn dort können via php_flag Einstellungen gesetzt werden:

<IfModule mod_php7.c>
  php_flag display_errors Off
</IfModule>

Die notwendige Angabe der PHP-Versionsnummer ist hier aber arg hinderlich (und erst ab PHP 8 nicht mehr nötig) und funktioniert zudem, je nach Installationsart von PHP auf dem Server nicht immer. Dann ist entweder eine php.ini oder eine .user.ini im Root-Ordner notwendig, mit dem folgenden Inhalt:

display_errors = 0

Die Werte können dabei 0/1, false/true oder on/off sein.

Was hat das Ganze nun mit Hostern zu tun? Leider ist der Wert für display_errors bei vielen Hostern standardmäßig aktiviert. Leider auch bei meinem Hoster domainfactory, der aber wunderbarerweise und im Gegensatz zu fast allen anderen Hostern eine sehr einfache Möglichkeit bietet, dass mit einem Klick zu deaktivieren:

Viele Hoster haben den Wert standardmäßig an: Siteground, IONOS, all-inkl.com, … – und einfache Möglichkeiten dies zu deaktivieren sind meist nicht vorhanden oder schlecht dokumentiert. Während der Entwicklungsphase ist das ja in Ordnung und hilfreich, aber beim Wechsel in den Live-Betrieb, muss diese Einstellung eigentlich einfach deaktiviert werden können. Und das bietet kaum ein Hoster an. Selbst bei domainfactory sind über und unter dem Screenshot oben noch viele weitere Einstellungsmöglichkeiten, die einen Laien schon wieder abschrecken. Den eigentlich guten Text, wird wohl kaum jemand lesen, der nicht vom Fach ist. Und damit verpufft leider die gute Idee schon wieder …

Gibt es Hoster bei denen das besser gelöst ist? Ich würde mich freuen gute Umsetzungen zu dem Thema zu sehen. Schreibt es mir in die Kommentare!


Dieser Artikel ist Teil der Serie: Hosting-Adventskalender
Alle Artikel findest du über das Schlagwort Adventskalender

Eine Antwort auf Fehleranzeige trotz Debug-Mode false

  1. Bei InternetWerk (www.wp-hosting.de) lassen sich Fehlermeldungen (display_errors) per Klick auf dem Server ein- und ausschalten. Da auch dort diese Funktion etwas versteckt ist, habe ich den Support gebeten, dies besser zu dokumentieren. Man verspricht nachbesserung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert