Das wpcheck-Tool von Sergej Müller

Die Zeiten ändern sich.

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

WordPress hat den Ruf unsicher zu sein. Das ist zum einen falsch, weil WordPress selbst nicht unsicherer als andere CMS ist, aber auch wahr, weil es viele Themes und Plugins gibt, die von Hobby-Entwicklern erstellt werden und Sicherheitslücken enthalten oder Themes/Plugins werden nicht mehr weiter entwickelt und versauern unbemerkt in den Sites und Lücken werden deshalb nicht mehr geschlossen. Ich halte bekannterweise nicht viel von All-in-one-Sicherheitsplugins. Daher möchte ich euch heute mal des Tool wpcheck von Sergej Müller vorstellen. wpcheck ist ein Node.js Kommandozeilen-Tool, mit dem WordPress-Websites nach bekannten Schwachstellen, Sicherheitsproblemen und Fehlkonfigurationen durchsucht werden können.

Das Tool ist schon ein wenig älter, funktioniert aber bei mir noch tadellos. Nach der Installation habe ich mal direkt meine Website getestet und war doch etwas überrascht:

Wieso kommt denn https://torstenlandsiedel.de is affected by FPD vulnerability?

FPD steht für Full Path Diclosure. Es geht also darum, dass eine Fehlermeldung den gesamten Serverpfad ausgibt. wpcheck testet das indem die Site https://torstenlandsiedel.de/wp/wp-includes/rss.php aufgerufen wird und prüft ob dort der Text „_deprecated_file“ gefunden wird.

Das ist schräg, weil in meiner .htaccess eigentlich folgende Zeilen stehen:

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

Offensichtlich ignoriert DomainFactory (und noch ein paar mehr Hoster, wie 1und1/Ionos oder all-inkl.com) diese Einstellung. Das möchte ich natürlich ändern. Dafür gibt es jetzt mehrere Möglichkeiten. DomainFactory bietet zum einen den PHP.INI-Editor im Hoster-Backend an:

Dort kann ich die PHP.INI bearbeiten und so auch mit einem einfachen Klick die Einstellung ändern:

Schräg, dass die Einstellung standardmäßig aktiv ist, obwohl im Erklärtext explizit davor gewarnt wird, dies auf öffentlich zugänglichen Websites aktiv zu haben. Der typische Anwender wird wohl kaum so tief in die Materie einsteigen, um dort den Haken zu entfernen.

Ich befürchte, dass bei jeder Umstellung der PHP-Version diese Einstellung neu gesetzt werden muss, daher habe ich noch eine andere Lösung. Über eine .user.ini-Datei im Root klappte es auch. Praktischerweise ist diese Lösung auch für die meisten anderen Hoster nutzbar. Einfach folgenden Inhalt in die Datei einfügen:

display_errors = 0

Und siehe da, jetzt zeigt ein erneuter Test auch an, dass wir das Problem gelöst haben:

Wie sieht es bei euch aus? Habt ihr auch das FPD-Problem? Konntet ihr es mit der obigen Variante lösen? Wenn nicht, bei welchem Hoster seid ihr? Vielleicht finden wir den Kommentaren eine Lösung!


Update 15. März 2020:
Es gibt auch schon ein Trac-Ticket zu der „Full Path Disclosure“-Problematik. Offizielle Aussage ist, dass es kein Sicherheitsproblem ist, denn display_errors sollte in Produktion immer deaktiviert sein. Schwierig nur, wenn dir niemand sagt, dass du ein Problem hast …

7 Antworten auf Das wpcheck-Tool von Sergej Müller

  1. Den WPCheck kannte ich noch nicht. Ich habe es gleich mal getestet und festgestellt dass auch bei Siteground „display_errors“ standardmäßig eingeschaltet ist. Kann aber über deren „PHP Manager“ umgeschaltet werden.

    Die meisten Webhostern lassen PHP nicht als Apache-Module laufen, sondern nutzen FastCGI mit PHP-FPM. Daher zieht IfModule auch nicht. Leider habe ich (noch) nicht herausgefunden wie das in der .htaccess abgefragt werden kann.

  2. Hatte ich auch nicht mehr auf dem Schirm. Sollte man eigentlich nach jeder Änderung am Webserver einmal laufen lassen.

  3. Danke für den Hinweis!

    Gerade bei mir laufen lassen und dadurch dran erinnert worden, dass ich noch den Debug-Mode mit `debug.log` aktiv hatte. Erst mal deaktiviert.

  4. Schöne Erinnerung an das Tool.
    War noch nie dazu gekommen es in meinen Alltag zu integrieren.

    Das mache ich nun mal.

  5. Pingback: Fehleranzeige trotz Debug-Mode false › Torsten Landsiedel

Schreibe einen Kommentar

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