Prima che accada qualcosa

Il tuo sito Joomla! ha un'estensione vulnerabile? Una checklist

Non è la stessa domanda di "il mio sito è stato hackerato": quella riguarda i segnali di una compromissione attiva, e la trattiamo separatamente per i siti Joomla! 3 nella nostra checklist per siti hackerati. Questa arriva prima ed è più silenziosa: come capisci, prima che accada qualcosa, se una delle tue estensioni installate ha una vulnerabilità nota che resta lì, senza patch?

Segnali manuali che puoi controllare oggi

  • Confronta la versione del core del tuo Joomla con l'ultima release disponibile. Sistema → Aggiornamento Joomla segnala lo scostamento di versione, anche se segnala qualsiasi release più recente, non specificamente lo stato di vulnerabilità.
  • Controlla se il feed VEL di Joomla stesso elenca per nome una delle tue estensioni installate. Guarda come è strutturato il feed stesso prima di cercarlo manualmente.
  • Leggi il changelog di ogni estensione cercando un linguaggio legato alla sicurezza. Termini come "security fix", "XSS" o "SQL injection", anche senza un CVE formale associato, meritano un ulteriore controllo.
  • Segna le estensioni senza aggiornamenti da molto tempo. Un'estensione ferma da due o più anni non è necessariamente stata riverificata rispetto alle classi di vulnerabilità scoperte da allora.
  • Controlla Sistema → Estensioni per qualsiasi cosa installata ma mai davvero utilizzata. Un'estensione inutilizzata esegue comunque codice e porta comunque con sé ogni vulnerabilità che ha.

Perché questo approccio manuale non regge

Ognuno di questi controlli richiede qualche minuto per una singola estensione. Un tipico sito Joomla ne conta tra 20 e 50, contando componenti, plugin, moduli e template, e un'agenzia che gestisce un portfolio di siti clienti moltiplica ulteriormente questo numero. Il controllo manuale, uno per uno, funziona bene come verifica una tantum. Non funziona come pratica continuativa, perché nessuno ripete davvero un controllo manuale di 30 minuti ogni settimana su decine di siti, e una vulnerabilità divulgata in un'estensione installata sei mesi fa è reale esattamente quanto una divulgata ieri, se nessuno l'ha più riverificata da allora.

Come funziona l'automazione

Questo è esattamente il vuoto che Houston colma: esegue automaticamente ogni giorno i controlli VEL e Security Centre descritti sopra, sull'inventario effettivamente installato, e invia un'e-mail solo quando un risultato è davvero nuovo. Guarda come configurarlo per smettere di farlo a mano. Se vieni da WordPress, guarda come si confronta con Wordfence e WPScan.

← Torna a Houston

Domande frequenti

Zero vulnerabilità in VEL per un'estensione significa che è sicura?

No. Significa solo che finora non è stato segnalato nulla, non che non esista nulla. VEL è un registro di problemi noti e divulgati, non una garanzia.

E se un'estensione non ha proprio nessun changelog da controllare?

Anche questo è un elemento da tenere presente. Nessun changelog di solito significa anche nessuna visibilità sul fatto che i problemi noti vengano mai risolti.

Quanto tempo richiede davvero controllare un sito a mano?

Qualche minuto per estensione, quindi un'ora o più per un tipico sito con 20-50 estensioni, e va ripetuto regolarmente per restare aggiornati, non fatto una sola volta.

Le estensioni inutilizzate e disabilitate vanno comunque controllate?

Sì. I file di un'estensione disabilitata sono di solito ancora presenti sul server. Se viene mai riabilitata, o se il suo codice è raggiungibile direttamente, ogni vulnerabilità che ha resta reale.