Bloccare l'esecuzione di PHP in modules/ con .htaccess (PrestaShop 1.7 e 8)

Uno dei miglioramenti di sicurezza meno citati di PrestaShop 9 sta in un file di una dozzina di righe: il .htaccess che la cartella modules/ porta di serie. Con questo, Apache risponde 403 a qualsiasi richiesta diretta a un .php di un modulo, prima ancora che PHP si avvii.

In PrestaShop 1.7 e 8 quel file non esiste. Qualsiasi .php presente in modules/, che sia di un modulo installato, di uno disinstallato o di una backdoor, si può richiamare da URL e viene eseguito. Questo articolo spiega come portare quella protezione nel tuo negozio senza rompere nulla.

Perché è importante

Quasi tutto ciò che fa un modulo moderno passa dal dispatcher di PrestaShop: i controller front si richiamano come index.php?fc=module&module=nombre&controller=accion (o il loro URL semplificato), e quelli di amministrazione passano dal back office. Nessuno di questi percorsi ha bisogno di richiamare direttamente un .php di modules/.

Quello che invece si richiama direttamente sono:

• File datati di moduli vecchi: ajax.php, validation.php, script di cron o di importazione che avviano PrestaShop per conto loro. Alcuni hanno vulnerabilità note.
• File di moduli orfani, che restano sul disco anche se il modulo è stato disinstallato.
• Backdoor lasciate nella cartella di un modulo, spesso con un nome che sembra lì da sempre.

Negare i .php diretti chiude in un colpo tutte e tre le cose. Resta aperto solo ciò che passa dal dispatcher, che è molto più facile da controllare.

Cosa fa esattamente PrestaShop 9

Il file di serie usa un FilesMatch che nega per estensione, con le direttive di Apache 2.2 e di Apache 2.4. Nega .php e anche altri file che non dovrebbero mai essere serviti da lì: .log, .txt, .lock, .json, .yml, .yaml, .tpl, .twig, il config.xml di ogni modulo e le sue varianti per lingua. CSS, JavaScript e immagini dei moduli continuano a essere serviti normalmente.

Come applicarlo in PrestaShop 1.7 e 8

1. Fai un elenco di ciò che viene richiamato direttamente. Prima di chiudere, controlla i log di accesso del server delle ultime settimane cercando richieste a /modules/ che finiscono in .php e rispondono 200. Quello è l'elenco di ciò che potresti rompere.
2. Classifica ciascuna. Ritorni dai gateway di pagamento, cron pianificati nel pannello, chiamate Ajax di qualche modulo vecchio. Ognuna è o un'eccezione giustificata o qualcosa che conviene sostituire.
3. Crea il file modules/.htaccess con un divieto per i .php e per le estensioni di configurazione, sul modello di quello di PrestaShop 9. In Apache 2.4 la regola essenziale è <FilesMatch "\.(php|phtml|phar|php[0-9])$"> Require all denied </FilesMatch>. Includere phtml, phar e le varianti numerate evita che passi un file con un'altra estensione che il server esegue comunque.
4. Aggiungi le eccezioni nella cartella di ciascun modulo, non in quella generale. Per esempio, in modules/mipasarela/.htaccess: <Files "notificacion.php"> Require all granted </Files>. Così l'eccezione vale solo per quel file di quel modulo, e non per qualsiasi file con lo stesso nome in un'altra cartella.
5. Verifica con richieste reali. Richiama un .php qualsiasi di un modulo (deve dare 403), richiama quello dell'eccezione (deve rispondere) e fai un ordine di prova con ogni metodo di pagamento.
6. Controlla i cron. Se un cron del pannello richiamava modules/x/cron.php, ora fallirà senza avvisare. Sostituiscilo con l'URL del controller del modulo se esiste, o lascialo come eccezione.

Limiti da conoscere

• Non protegge i controller front. Un controllers/front/ viene servito tramite index.php, quindi il .htaccess di modules/ non lo copre. Se un modulo installato ha un controller vulnerabile, resta vulnerabile. Lì non ci sono scorciatoie: aggiornare o rimuovere il modulo.
• Nginx ignora i .htaccess. Se il tuo server è Nginx puro, il divieto si imposta con un blocco location nella configurazione del server, di cui di solito si occupa il tuo hosting.
• Dipende dal fatto che il server legga i .htaccess (direttiva AllowOverride). Verificalo richiamando un .php dopo aver creato il file; non darlo per scontato.
• Un attaccante con permessi di scrittura può cancellarlo. Se qualcuno può scrivere in modules/, può togliere il .htaccess. La sua scomparsa non ha alcuna causa legittima, quindi sorvegliarne la presenza è di per sé un allarme utile.

Le altre cartelle: upload/, img/, var/

upload/ e download/

Lì finiscono i file che i clienti caricano nei prodotti personalizzabili e i prodotti scaricabili. PrestaShop li serve tramite un controller, non con accesso diretto. In PrestaShop 9, download/ nega tutto e upload/ nega i file con il nome interno che assegna PrestaShop. Nessuna delle due dovrebbe mai contenere un .php, quindi aggiungere un divieto di PHP è sicuro. Se inoltre il tuo negozio non serve nulla di upload/ tramite URL diretto, puoi negare tutto, ma verificalo prima.

img/

In PrestaShop 9 nega tutto tranne le estensioni di immagini, video, PDF e icone. Nelle versioni precedenti, controlla cosa contiene il tuo img/.htaccess: può avere regole proprie, quindi aggiungi il divieto di PHP in fondo, senza sostituire ciò che c'è. E quando rigeneri il .htaccess della radice dal back office, verifica poi che i tuoi blocchi siano ancora dove li avevi lasciati.

var/ e cache/

Dalla 1.7, var/ ha un divieto totale. Verifica che il file sia ancora lì: un var/logs accessibile rivela percorsi, errori e a volte dati dei clienti. Nei negozi 1.6 la cartella equivalente è cache/, e non deve servire PHP.

La radice

Controlla anche che nella radice non ci siano backup (.zip, .sql, .tar.gz) né log degli errori dell'hosting accessibili. Un dump del database scaricabile è peggio di qualsiasi shell.

Come risolverlo in PrestaShop

RKR Security Alert ha un pannello di blindatura delle cartelle di dati che verifica che il .htaccess di upload/, download/, img/ e altre cartelle non solo esista, ma blocchi davvero l'esecuzione, e avvisa se compare qualcosa di eseguibile dove dovrebbero esserci solo dati. Può scrivere il blocco di divieto al posto tuo, aggiungendolo in fondo al file esistente e salvandone una copia. Per modules/, controlla quali estensioni nega realmente il .htaccess e le incrocia con i punti di ingresso che trova, e ogni risultato dello scanner indica se è raggiungibile da URL o è chiuso. Se preferisci non metterci mano tu, con un pacchetto di ore di assistenza di Rekire controlliamo i log, definiamo le eccezioni necessarie e lo proviamo con ordini reali.