Audit di sicurezza di un negozio PrestaShop: cosa controllare e in che ordine

Ci sono due momenti per fare l'audit di un negozio: quando sospetti che qualcosa non vada e quando tutto sembra andare bene. Il primo è urgente; il secondo è quello che evita il primo. In entrambi i casi la lista è la stessa, e l'ordine conta: prima ciò che permette di entrare e restare, poi ciò che permette di incassare, e alla fine ciò che permette di riprendersi.

Questa non è una lista di buone pratiche di configurazione, ma di controlli concreti: cosa aprire, cosa cercare e che cosa significa ciò che trovi.

Prima di iniziare: non distruggere le prove

Se l'audit nasce da un sospetto, fai prima una copia completa di file e database così come sono, e lavora su quella ogni volta che puoi. Se c'è un'infezione, dovrai sapere da quando e cosa ha toccato, e queste informazioni si perdono con la pulizia.

Un'altra regola: non dare nulla per buono mentre controlli. Se il tuo strumento di sorveglianza crea una baseline di «stato normale», non crearla finché non hai finito. Una baseline fatta su un negozio compromesso considera buona l'infezione per sempre.

1. Dipendenti

• Elenca tutti i dipendenti e i loro profili. Riconosci tutti i superamministratori?
• Cerca account con identificativi consecutivi in fondo all'elenco, email estranee o nomi vuoti: è la traccia tipica di una SQL injection.
• Controlla gli account di persone che non lavorano più con te, di vecchie agenzie e di test. Un account inattivo dimenticato è una porta.
• Verifica che tutti quelli che devono averla abbiano l'autenticazione a due fattori attiva.

2. Account del webservice

È la porta di cui nessuno si ricorda. Controlla in Parametri Avanzati → Webservice:

• Quante chiavi ci sono, a cosa serve ciascuna e se qualcuna non ha una descrizione.
• Quali permessi hanno. La scrittura sulla configurazione o qualsiasi permesso sui dipendenti è molto potere.
• Se il webservice è attivo senza HTTPS forzato, la chiave viaggia in chiaro.

Non disattivare una chiave «per sicurezza» senza sapere cos'è: di solito è l'integrazione con l'ERP o con un marketplace.

3. Moduli

• Elenca i moduli installati con la loro versione e confrontala con l'ultima pubblicata dall'autore.
• Cerca quelli con avvisi di sicurezza pubblicati e quelli abbandonati.
• Cerca le cartelle in modules/ senza un modulo registrato: gli orfani.
• Diffida dei moduli senza un autore riconoscibile, con compatibilità impossibili o con descrizioni che non spiegano nulla.
• Controlla override/: ogni file lì dentro modifica il core.

4. File modificati

Il controllo più prezioso non dipende dal riconoscere alcun pattern:

• Confronta il core con lo ZIP ufficiale della tua versione esatta, vendor/ compresa. Un file del core non dovrebbe mai cambiare se non per un aggiornamento.
• Confronta ogni modulo con il suo pacchetto originale. Ciò che non era nel pacchetto l'ha messo qualcuno.
• Cerca PHP dove non deve esserci: upload/, download/, img/, immagini con codice dentro.
• Cerca file JavaScript con righe sproporzionate incollate all'inizio o alla fine.
• Diffida delle date, che si possono falsificare. Quello che conta è il contenuto.

5. Template e configurazione dei pagamenti

È lì che l'attaccante incassa, quindi merita un punto a sé:

• Controlla i template del checkout di tutti i temi installati, non solo quello attivo, cercando tag <script> che non riconosci.
• Verifica i dati di ogni metodo di pagamento: l'IBAN del bonifico, le chiavi dei gateway, gli account PayPal.
• Controlla i moduli che permettono di inserire HTML o codice nell'intestazione o nel piè di pagina.
• Confronta gli ordini pagati delle ultime settimane con quanto è arrivato in banca o sul gateway.

6. Configurazione del negozio

• Gli URL del negozio (dominio e percorsi): una modifica qui dirotta il traffico.
• La configurazione della posta in uscita: un SMTP modificato permette di leggere o deviare le email.
• La modalità debug disattivata in produzione e la cartella install/ cancellata.
• La cartella del back office con un nome diverso da quello predefinito.

7. Attività pianificate

Un cron malevolo vive fuori dall'albero web, quindi nessuna scansione dei file lo vede. Controlla le attività nel pannello dell'hosting e, se hai accesso, il crontab dell'account. Una riga che scarica qualcosa e lo passa a una shell, che decodifica base64 o che esegue PHP in linea non ha alcun uso legittimo. Controlla anche le chiavi SSH autorizzate dell'account.

8. .htaccess e permessi

• Il .htaccess della radice: cerca reindirizzamenti condizionati al browser o alla provenienza, che colpiscono solo i dispositivi mobili o chi arriva da un motore di ricerca.
• I .htaccess di upload/, img/, download/ e var/: che esistano e che blocchino davvero l'esecuzione.
• In PrestaShop 8 e precedenti, se modules/ permette di eseguire .php da URL.
• Che non ci siano cartelle scrivibili da chiunque né file di configurazione leggibili da tutti.

9. Log

• Log di accesso del server web: richieste POST a file di moduli che non conosci, o molte richieste allo stesso controller poco prima di una modifica.
• Log dell'FTP e del pannello dell'hosting, che sono indipendenti da quelli web.
• Log degli errori di PHP e di PrestaShop: un errore nuovo in un file che non ha cambiato versione è un indizio.
• Verifica che nessun log sia raggiungibile da URL dall'esterno.

10. Backup

• Esistono, sono giornalieri e stanno fuori dal server?
• Sono mai stati ripristinati per verificare che funzionino?
• Ci sono vecchie copie sparse nella radice del sito, scaricabili da chiunque?
• Fino a quando risalgono? Se l'infezione ha mesi, ti serve una copia precedente.

E alla fine

Con tutto controllato e pulito, adesso sì: crea la baseline di integrità, cambia le credenziali e lascia la sorveglianza in funzione. E annota ciò che è emerso sulle versioni: se il negozio è su un PrestaShop o un PHP senza supporto, o con moduli che non si possono aggiornare, il prossimo audit troverà le stesse cose. Tenere il negozio aggiornato è ciò che rende breve il controllo successivo.

Come risolverlo in PrestaShop

RKR Security Alert automatizza buona parte di questa lista: sorveglia dipendenti, moduli, configurazione (con le modifiche ai pagamenti segnate come critiche), URL del negozio e account del webservice; confronta il core con lo ZIP ufficiale; analizza i file alla ricerca di backdoor, web shell e skimmer; controlla l'hash dei template del checkout di tutti i temi; verifica le attività pianificate e la blindatura delle cartelle, ed esegue 14 controlli sulla configurazione del server. Si installa in modalità primo audit, senza baseline finché non dai per verificato il report. RKR Sentinel aggiunge la sorveglianza degli errori e dei pagamenti che non diventano ordini. E se vuoi un audit fatto da persone, con un pacchetto di ore di assistenza di Rekire lo facciamo noi, ripuliamo ciò che emerge e ti consegniamo ciò che resta in sospeso.