Verwaiste Module in PrestaShop: Code, den niemand ansieht und der weiter antwortet

Ein Shop, der seit Jahren läuft, sammelt Module wie ein Keller Kartons. Man hat ein Bewertungsmodul getestet, den Zahlungsanbieter gewechselt, etwas für eine Weihnachtsaktion installiert. Im Backoffice wurde alles deinstalliert, aber die Ordner sind noch da, in modules/, mit ihrem gesamten Code.

Diese Ordner nennen wir verwaiste Module. Sie erscheinen nicht im Modulmanager, niemand aktualisiert sie, und in vielen Shops antwortet ihr PHP weiterhin jedem, der es per URL aufruft.

Warum Module verwaisen

• Deinstallieren ist nicht Löschen. In PrestaShop führt das Deinstallieren die Methode uninstall() des Moduls aus (die seine Tabellen und seine Konfiguration entfernt), aber der Ordner kann auf der Festplatte bleiben. Ihn zu löschen ist ein eigener Schritt, und oft unterbleibt er.
• Migrationen und Kopien. Beim Migrieren oder Wiederherstellen werden Modulordner kopiert, die im neuen Shop nie installiert werden.
• Uploads per FTP. Jemand hat ein Modul zum Testen per FTP hochgeladen und es nie installiert.
• Reste von Themes. Manche kommerziellen Themes bringen eigene Module mit; beim Theme-Wechsel bleiben die des alten zurück.

Warum sie ein Risiko sind

Verwundbarer Code, der nie aktualisiert wird

Ein installiertes Modul erscheint, auch wenn es alt ist, wenigstens in der Liste, und jemand kann sehen, dass es ein Update gibt. Ein verwaistes erscheint nirgends. Hatte seine Version eine bekannte Schwachstelle, behält es sie für immer.

Sein PHP wird weiterhin ausgeführt

Das ist der entscheidende Punkt. Dass das Modul nicht installiert ist, hindert seine Dateien nicht daran zu antworten. Viele alte Module enthalten PHP-Dateien, die direkt per URL aufgerufen werden sollen: eine ajax.php, eine validation.php, ein Importskript. Diese Dateien starten PrestaShop selbst und erledigen ihre Arbeit, ob registriert oder nicht.

In PrestaShop 8 und älter hat der Ordner modules/ ab Werk keinen Schutz, der die Ausführung dieser .php verhindert. PrestaShop 9 bringt dagegen eine .htaccess in modules/ mit, die direkt aufgerufene .php verweigert, was einen Großteil des Problems unter Apache und LiteSpeed löst. Front-Controller, die über den Dispatcher von PrestaShop laufen, bleiben aber erreichbar, wenn das Modul installiert ist, und unter Nginx wird die .htaccess ignoriert.

Ein bequemes Versteck

Für einen Angreifer ist ein Ordner, den niemand ansieht, der ideale Ort für eine Hintertür. Eine neue Datei in einem verwaisten Modul fällt mit viel geringerer Wahrscheinlichkeit auf als eine im Stammverzeichnis.

Wie Sie eine Bestandsaufnahme machen

Die Idee ist, zwei Listen abzugleichen: die Ordner in modules/ auf der Festplatte und die in der Datenbank registrierten Module.

1. Erstellen Sie die Liste der registrierten Module. In der Datenbank: SELECT name, active, version FROM ps_module ORDER BY name;
2. Erstellen Sie die Liste der Ordner in modules/, über den Dateimanager des Hostings oder per SSH.
3. Ordner, die nicht in der ersten Liste stehen, sind verwaist. Notieren Sie zu jedem: ob er .php-Dateien außerhalb von controllers/ enthält, seine Version (in config.xml oder in der Hauptdatei) und das Datum seiner Dateien.
4. Unterscheiden Sie installierte, aber deaktivierte Module. Diese stehen in der Liste, verdienen aber ebenfalls eine Prüfung: Werden sie nicht genutzt, sollten Sie sie deinstallieren und löschen.
5. Markieren Sie verdächtige. Ein Modul mit unbekanntem Autor, ohne Dokumentation, mit einer unmöglichen angegebenen Kompatibilität oder einer Beschreibung, die nichts beschreibt, hat wahrscheinlich niemand aus Ihrem Team installiert.

Wie Sie sie entfernen, ohne das Theme zu beschädigen

Einen Ordner zu löschen scheint trivial, aber manchmal hängt etwas davon ab:

• Theme-Templates, die Dateien eines Moduls einbinden. Manche Themes rufen Templates oder CSS bestimmter Module direkt auf. Suchen Sie vor dem Löschen im Theme-Ordner nach dem Modulnamen.
• Verwaiste Overrides. Ein deinstalliertes Modul kann Dateien in override/ hinterlassen haben, die weiterhin ausgeführt werden. Prüfen Sie diesen Ordner, und wenn Sie einen Override entfernen, leeren Sie auch den Klassen-Cache.
• Module, die ein anderes Modul als Bibliothek nutzt. Das kommt bei manchen Paketen vor, die einen gemeinsamen Ordner zwischen mehreren Modulen desselben Autors teilen.
• Externe Cronjobs, die eine Datei des Moduls aufrufen. Hat das Hosting-Panel eine geplante Aufgabe, die auf diesen Ordner zeigt, schlägt sie fehl; das wissen Sie besser vorher.

Das sichere Vorgehen:

1. Erstellen Sie ein Backup von Dateien und Datenbank.
2. Statt zu löschen, verschieben Sie den Ordner aus dem Webverzeichnis heraus (oder benennen Sie ihn um, wenn es nicht anders geht) und warten Sie einige Tage.
3. Klicken Sie sich durch den Shop, machen Sie eine Testbestellung, prüfen Sie das Backoffice und die Fehlerprotokolle.
4. Hat sich nichts beschwert, löschen Sie ihn endgültig.
5. Wiederholen Sie die Bestandsaufnahme alle paar Monate oder jedes Mal, wenn etwas deinstalliert wird.

Was Sie außerdem tun sollten

• Sperren Sie die direkte Ausführung von PHP in modules/, wenn Ihr Shop älter als PrestaShop 9 ist, mit Ausnahmen nur für die Dateien, die es wirklich brauchen.
• Scannen Sie verwaiste Module vor dem Löschen: Enthält eines eine Hintertür, wissen Sie nach bloßem Löschen weder, wie der Angreifer hereinkam, noch, was er sonst getan hat.
• Nutzen Sie eine Migration, um mit einem sauberen modules/ neu zu beginnen: In einen neuen Shop kommt nur, was wirklich installiert wird. Das ist einer der am seltensten erwähnten Vorteile, eine 1.6 oder 1.7 mit jahrelangen Altlasten hinter sich zu lassen.

So lösen Sie es in PrestaShop

RKR Security Alert sucht in modules/ nach Ordnern ohne Eintrag in der Datenbank und stuft ihre Schwere nach dem Inhalt ein: informativ, wenn nur Ressourcen darin liegen, kritisch, wenn es erreichbares PHP mit Funden gibt. Es prüft außerdem, welche Endungen die .htaccess von modules/ tatsächlich verweigert, und gleicht sie mit den gefundenen Einstiegspunkten ab, um zu beantworten, wie viele Moduldateien jeder von außen aufrufen kann; zudem zählt es die installierten Module, die nicht von der Integritäts-Baseline erfasst sind. Wenn Sie es lieber uns überlassen, erfassen wir mit einem Rekire-Support-Stundenpaket die Module Ihres Shops, entfernen überflüssige, nachdem wir geprüft haben, dass das Theme intakt bleibt, und hinterlassen Ihnen eine Liste dessen, was aktualisiert werden sollte.