«Ma è solo un plugin per il modulo contatti». «Quel tema non lo uso più, è solo installato». Sono frasi che sentiamo spesso, e partono da un’idea comprensibile: che una falla in un pezzo secondario del sito resti confinata lì. Purtroppo non funziona così. In WordPress, WooCommerce e PrestaShop un’estensione vulnerabile può mettere a rischio tutto il sito, il database, i dati dei clienti e a volte anche la reputazione del dominio. Vediamo perché, e come ridurre il rischio senza rinunciare alle estensioni che ti servono.
Un’estensione non vive in una stanza separata
Quando installi un plugin, un tema o un modulo, il suo codice gira con gli stessi permessi del sito. Può leggere e scrivere nel database, creare e modificare file nella cartella del sito, gestire utenti, inviare email. È proprio questo che lo rende utile: un plugin per i moduli deve poter salvare i messaggi, un modulo di pagamento deve poter modificare gli ordini.
Ma significa anche che, se quel codice contiene una falla, chi la sfrutta ottiene quegli stessi poteri. Non esiste un recinto che limiti i danni al «solo modulo contatti»: il punto d’ingresso è piccolo, ma la casa a cui dà accesso è la stessa.
Cosa può succedere, in concreto
Le conseguenze dipendono dal tipo di falla. Le più comuni, in ordine crescente di gravità:
| Tipo di falla | Cosa permette, in parole semplici |
|---|---|
| Cross-site scripting (XSS) | Inserire script nelle pagine, che vengono eseguiti nel browser dei visitatori o, peggio, dell’amministratore |
| Scalata di privilegi | Un utente con pochi permessi, per esempio un cliente registrato, diventa amministratore |
| SQL injection | Leggere o modificare il database: ordini, indirizzi, account |
| Caricamento arbitrario di file | Mettere sul sito un file eseguibile scelto dall’attaccante |
| Esecuzione di codice da remoto | Far girare comandi a piacere: di fatto, il controllo del sito |
Una volta dentro, gli obiettivi tipici sono sempre gli stessi: lasciare una porta di servizio (backdoor) per tornare anche dopo la correzione, inserire redirect e link di spam, rubare credenziali e dati dei clienti, usare il sito per inviare spam o attaccare altri siti.
Perché le estensioni sono il bersaglio preferito
Il nucleo di WordPress e quello di PrestaShop sono progetti molto seguiti, con molti occhi che ne controllano il codice e processi di rilascio collaudati. Le estensioni, invece, sono migliaia, scritte da sviluppatori con risorse e attenzione alla sicurezza molto diverse. Non a caso molte delle falle di WordPress e PrestaShop non stanno nel nucleo, ma proprio nelle estensioni.
C’è poi un fattore di scala: un plugin installato su moltissimi siti è un bersaglio ideale per gli attacchi automatici. Chi attacca non sceglie il tuo sito: scrive un programma che cerca quel plugin, in quella versione, su tutti i siti che trova, e prova la falla.
I casi più insidiosi
Il plugin disattivato
Disattivare un plugin non lo rimuove: i suoi file restano nella cartella del sito. In molti casi un plugin disattivato non viene eseguito, ma ci sono falle che si possono raggiungere chiamando direttamente un file dell’estensione. La regola pratica è semplice: quello che non usi, eliminalo.
Il tema «di riserva»
Vale lo stesso per i temi: i vecchi temi installati e mai aggiornati sono codice in più sul server, che nessuno controlla. Tieni il tema attivo e, se vuoi, un solo tema predefinito aggiornato come riserva.
Il componente abbandonato
A volte uno sviluppatore smette di mantenere un plugin o un modulo. Le falle scoperte dopo non verranno mai corrette. Se un’estensione non riceve aggiornamenti da molto tempo o è stata ritirata dal catalogo ufficiale, è il momento di cercare un’alternativa.
La versione «gratuita» di un prodotto a pagamento
Temi e plugin commerciali scaricati da siti non ufficiali spesso contengono codice malevolo già all’origine, e in ogni caso non ricevono gli aggiornamenti di sicurezza. Il risparmio iniziale si paga caro.
La libreria dentro il plugin
Molte estensioni includono a loro volta librerie di terze parti. Una falla in una di queste può colpire il plugin anche se il suo codice è scritto bene: per questo è importante aggiornare anche quando le note di rilascio parlano solo di «librerie aggiornate».
Come ridurre il rischio
- Installa solo ciò che serve: ogni estensione in più è codice in più da tenere d’occhio.
- Scegli estensioni mantenute: guarda la data dell’ultimo aggiornamento, la compatibilità con la versione del CMS, la reputazione dello sviluppatore.
- Scarica solo da fonti ufficiali: il catalogo del CMS o il sito dello sviluppatore.
- Elimina quello che non usi, temi compresi.
- Aggiorna con regolarità, e subito quando l’aggiornamento è di sicurezza. Prima di farlo, ricorda che hai i backup automatici per tornare indietro.
- Proteggi gli account: password robuste e autenticazione a più fattori per gli amministratori, così una falla non si somma a una password debole.
Cosa facciamo noi
Proprio perché le estensioni sono il punto debole più frequente, la nostra Gestione vulnerabilità non si limita al nucleo: ogni notte controlla anche i plugin, i temi e i moduli installati nei siti che ospitiamo, confrontandoli con le banche dati delle vulnerabilità note. Quando una falla grave riguarda il tuo sito te lo comunichiamo e, quando serve, applichiamo una protezione mirata con Security Intelligence. Per alcune estensioni commerciali le informazioni pubbliche sono scarse: anche per questo aggiornarle resta importante.
Se il peggio è già successo, cPGuard analizza file e database alla ricerca di codice malevolo, e su richiesta offriamo un intervento di pulizia dal malware per rimettere il sito in sicurezza.
In sintesi
- Un plugin, un tema o un modulo gira con gli stessi poteri del sito: una sua falla espone tutto.
- Disattivato non vuol dire innocuo: ciò che non usi va eliminato.
- Poche estensioni, mantenute, da fonti ufficiali e sempre aggiornate: è la difesa più efficace.