Adventskalender Tag 8: Sicheres Debugging auf einem WordPress Live-System

Einige werden das Problem bestimmt kennen. Man installiert ein neues Plugin oder testet eine neue Funktion und auf einmal bekommt man nur einen weißen Bildschirm, statt der eigentlichen Seite angezeigt. In diesem Fall ist es dann notwendig ins Error-Log von PHP zu sehen, um den Fehler finden zu können.

Was aber, wenn man auf dem Hosting-Paket keinen Zugriff auf diese Datei hat oder nicht weißt, wo man sie finden kann? Oder aber ein Fehler tritt nur auf der Live-Seite auf, nicht aber in der lokalen Entwicklungsumgebung, in der wir ja vorher immer alles testen? 😉

Den Debug-Modus aktivieren

Dann kann es notwendig sein, den Debug-Modus auf einem Live-System zu aktivieren. Normalerweise findet man dann den Tipp, einfach in der wp-config.php Datei den Debug-Modus zu aktivieren, indem man die Konstante setzt:

define('WP_DEBUG', true);

Das funktioniert natürlich. Es hat nur einen sehr unschönen Nebeneffekt. Alle Fehler, aber auch Warnungen und Hinweise werden für alle Nutzer sichtbar angezeigt:

wp-debug-notice

Selbst wenn man den Fehler schnell findet und den Modus dann wieder ausschaltet, sollten solche Meldungen niemals sichtbar sein. Es wirkt nicht nur sehr unprofessionell, es kann darüber hinaus auch sicherheitsrelevante Informationen über euren Blog preisgeben.

Debug-Meldungen vor den Besuchern verbergen

Für das Debugging von WordPress gibt es noch weitere Konstanten. Diese stehen aber nicht von Anfang an in der wp-config.php Datei. Mit diesen ist es möglich, die Fehler in eine Logdatei ausgeben zu lassen statt diese im Browser anzuzeigen. Um dies einzurichten, verwende folgende Konstanten:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Alle Fehler werden dann in die Datei /wp-content/debug.log geschrieben. Diese könnt ihr dann über den Browser aufrufen und speichern oder per FTP runterladen:

wp-debug-log

Gefahren durch den aktiven Debug-Modus

Ein auf einem Live-System aktivierten Debug-Modus birgt einige Gefahren. Wie schon zuvor erwähnt kann ein Angreifer durch die Fehler in der Logdatei Details über euer System in Erfahrung bringen. In der Meldung sind in der Regel der Dateiname und die Zeile sichtbar. Aber auch in den Fehlerdetails können kritische Informationen, bis hin zu Benutzernamen und Passwörtern stehen. Um dies abzusichern könntet ihr beispielsweise einen Aufruf der Datei (oder am besten gleich alle .log-Dateien) mit einem htaccess-Passwortschutz versehen:

<FilesMatch "\.log$">
AuthType Basic
AuthUserFile /path/to/.htpasswd
AuthName "Restricted area."
Require valid-user
</FilesMatch>

Eine weitere Gefahr ist die Dateigröße der Logdatei. Gerade bei einer WordPress Installation, bei der viele Warnungen und Hinweise ausgegeben werden, kann die Datei in kürzester Zeit viele Megabyte oder gar Gigabyte an Größe haben. Im schlimmsten Fall belegt sie dann den gesamten freien Speicherplatz eures Hosting-Pakets und eure Seite ist nicht mehr erreichbar. Ihr solltet also den Debug-Modus sofort deaktivieren, wenn ihr den Fehler gefunden oder genügend Informationen zu dessen Behebung gesammelt habt.

Erinnerung den Debug-Modus wieder zu deaktivieren

Natürlich habe ich selbst noch nie vergessen den Debug-Modus wieder zu deaktivieren. Genau deshalb ist meine Logdatei auch aktuell “nur” 540MB groß 🙂 Wenn es euch auch so geht, dass ihr so etwas gerne mal vergesst, dann habe ich eine schöne Lösung für euch. Ja, richtig geraten. Ich habe mal wieder schnell ein Plugin dafür gebastelt und auf GitHub gestellt. Also einfach wieder als ZIP-Datei runterladen, installieren und aktivieren.

Wenn der Debug-Modus dann aktiv ist, dann wird allen Nutzern mit Administratorrechten eine Warnung im gesamten Dashboard angezeigt:

wp-debug-active-warning

Fazit

Wie ihr gesehen habt, ist es sehr einfach, auch ein Live-System zu debuggen, ohne die Meldungen den Besuchern der Seite anzuzeigen. Ich hoffe ich konnte euch auch ein wenig auf die Gefahren aufmerksam machen, die hierdurch entstehen können.

Falls auch ihr einen tollen Tipp zum Thema Debugging habt, hinterlasst gerne einen Kommentar.

Veröffentlicht von

Bernhard ist fest angestellter Webentwickler, entwickelt in seiner Freizeit Plugin, schreibt in seinem Blog über WordPress und andere Themen, treibt sich gerne bei den WP Meetups in Berlin und Potsdam herum und läuft nach Feierabend den ein oder anderen Halbmarathon.

5 Kommentare » Schreibe einen Kommentar

  1. Der Frank Bültge hat in seinem WordPress-Starter was sehr Nettes:

    /**
     * Debugging via URL paramter. 
     * Get debug notices when applying “wp-debug=true” as a URL query.
     * http://example.com/?wp_debug=true
     * http://example.com/?s=foo&wp_debug=true
     * 
     * @link https://github.com/bueltge/WordPress-Starter/blob/master/wp-config.php#L3-L6
     */
    if ( isset( $_GET['wp_debug'] ) && $_GET['wp_debug'] === 'true' ) {
    	define( 'WP_DEBUG', true );
    } else {
    	define( 'WP_DEBUG', false );
    }
    

    Meinung? 🙂

    • Das ist prinzipiell natürlich auch eine Variante. Allerdings kann dann jeder, der den Namen des Request-Parameters kennt, den Debug-Modus einschalten. Und es funktioniert auch nicht für AJAX oder WP-API Requests. Aber als alternative Möglichkeit kann man es durchaus einsetzen. Ich würde dann nur den gesamten Code nach dem Debugging auskommentieren, um eben den Aufruf über den Parameter wieder zu verhindern.

    • Mir fällt gerade noch eine Variante ein, mit der man den Code von Frank etwas absichern könnte. Man verwendet als Parameter weiterhin wp_debug aber als Wert einfach einen “Token” und nicht einfach nur “true”. Den könnte zwar ein Angreifer immer noch abfangen, aber es wäre eben nicht mehr ganz so einfach wie einfach mal wp_debug=true bei einem Blog zu versuchen.

  2. Pingback: Lexikon der WordPress-Begriffe - WordPress1x1

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.