Moduli orfani in PrestaShop: il codice che nessuno guarda e che continua a rispondere

Un negozio con anni di attività accumula moduli come una cantina accumula scatoloni. Si è provato un modulo di recensioni, si è cambiato gateway di pagamento, si è installato qualcosa per una campagna di Natale. Sono stati disinstallati dal back office, ma le cartelle sono ancora lì, in modules/, con tutto il loro codice.

Queste cartelle le chiamiamo moduli orfani. Non compaiono nel gestore dei moduli, nessuno le aggiorna e in molti negozi il loro PHP continua a rispondere a chiunque lo richiami da URL.

Perché restano orfani

• Disinstallare non è cancellare. In PrestaShop, disinstallare esegue l'uninstall() del modulo (che rimuove le sue tabelle e la sua configurazione), ma la cartella può restare sul disco. Cancellarla è un'altra operazione, e spesso non si fa.
• Migrazioni e copie. Durante una migrazione o un ripristino si copiano cartelle di moduli che nel nuovo negozio non vengono mai installati.
• Caricamenti via FTP. Qualcuno ha caricato un modulo via FTP per provarlo e non l'ha mai installato.
• Residui dei temi. Alcuni temi commerciali portano i propri moduli; cambiando tema, quelli del precedente restano.

Perché sono un rischio

Codice vulnerabile che non viene mai aggiornato

Un modulo installato, anche se vecchio, almeno compare nell'elenco e qualcuno può vedere che c'è un aggiornamento. Un orfano non compare da nessuna parte. Se la sua versione aveva una vulnerabilità nota, continuerà ad averla per sempre.

Il suo PHP continua a essere eseguito

Ecco il punto importante. Il fatto che il modulo non sia installato non impedisce ai suoi file di rispondere. Molti moduli vecchi contengono file PHP pensati per essere richiamati direttamente da URL: un ajax.php, un validation.php, uno script di importazione. Questi file avviano PrestaShop per conto loro e fanno il loro lavoro, registrati o no.

In PrestaShop 8 e precedenti, la cartella modules/ non ha di serie alcuna protezione che impedisca di eseguire quei .php. PrestaShop 9 invece include un .htaccess in modules/ che nega i .php richiamati direttamente, e questo chiude gran parte del problema su Apache e LiteSpeed. Ma i controller front che passano dal dispatcher di PrestaShop restano accessibili se il modulo è installato, e su Nginx il .htaccess viene ignorato.

Un nascondiglio comodo

Per un attaccante, una cartella che nessuno guarda è il posto ideale per lasciare una backdoor. Un file nuovo dentro un modulo orfano ha molte meno probabilità di essere notato di uno nella radice.

Come fare l'inventario

L'idea è incrociare due elenchi: le cartelle di modules/ sul disco e i moduli registrati nel database.

1. Estrai l'elenco dei moduli registrati. Nel database: SELECT name, active, version FROM ps_module ORDER BY name;
2. Estrai l'elenco delle cartelle di modules/, dal file manager dell'hosting o via SSH.
3. Le cartelle che non sono nel primo elenco sono orfane. Annota per ciascuna: se ha file .php fuori da controllers/, la sua versione (in config.xml o nel file principale) e la data dei suoi file.
4. Distingui quelli installati ma disattivati. Quelli sono nell'elenco, ma meritano comunque una verifica: se non si usano, conviene disinstallarli e cancellarli.
5. Segna quelli sospetti. Un modulo con autore sconosciuto, senza documentazione, con una compatibilità dichiarata impossibile o con una descrizione che non descrive nulla probabilmente non l'ha installato nessuno del tuo team.

Come rimuoverli senza rompere il tema

Cancellare una cartella sembra banale, ma ci sono casi in cui qualcosa ne dipende:

• Template del tema che includono file di un modulo. Alcuni temi richiamano direttamente template o CSS di moduli specifici. Cerca il nome del modulo nella cartella del tema prima di cancellare.
• Override orfani. Un modulo disinstallato può aver lasciato file in override/ che continuano a essere eseguiti. Controlla quella cartella e, se togli un override, svuota anche la cache delle classi.
• Moduli che un altro modulo usa come libreria. Succede con alcuni pacchetti che condividono una cartella comune tra diversi moduli dello stesso autore.
• Cron esterni che richiamano un file del modulo. Se il pannello dell'hosting ha un'attività pianificata che punta a quella cartella, fallirà; meglio saperlo prima.

La procedura sicura:

1. Fai un backup di file e database.
2. Invece di cancellare, sposta la cartella fuori dalla directory web (o rinominala se non hai alternative) e lascia passare qualche giorno.
3. Naviga nel negozio, fai un ordine di prova, controlla il back office e i log degli errori.
4. Se nulla si è lamentato, cancellala definitivamente.
5. Ripeti l'inventario ogni pochi mesi, o ogni volta che si disinstalla qualcosa.

Cos'altro conviene fare

• Blocca l'esecuzione diretta di PHP in modules/ se il tuo negozio è precedente a PrestaShop 9, con eccezioni solo per i file che ne hanno davvero bisogno.
• Analizza gli orfani prima di cancellarli: se uno contiene una backdoor, cancellarlo e basta ti lascia senza sapere come sono entrati né che altro hanno fatto.
• Approfitta di una migrazione per ripartire con modules/ pulito: in un negozio nuovo entra solo ciò che si installa davvero. È uno dei vantaggi meno citati del lasciarsi alle spalle una 1.6 o una 1.7 con anni di residui.

Come risolverlo in PrestaShop

RKR Security Alert cerca dentro modules/ le cartelle senza registrazione nel database e ne gradua la gravità in base al contenuto: informativa se ci sono solo risorse, critica se c'è PHP raggiungibile con dei riscontri. Controlla anche quali estensioni nega davvero il .htaccess di modules/ e le incrocia con i punti di ingresso che trova, per dire quanti file di modulo chiunque può richiamare dall'esterno, e conta i moduli installati non coperti dalla baseline di integrità. Se preferisci che lo facciamo noi, con un pacchetto di ore di assistenza di Rekire facciamo l'inventario dei moduli del tuo negozio, rimuoviamo quelli di troppo verificando che non rompano il tema e ti lasciamo l'elenco di ciò che conviene aggiornare.