Quando accedi alla bacheca di WordPress e vedi un avviso che segnala la disponibilità di una nuova versione, la tentazione è di cliccare su più tardi e proseguire. Il numero di versione è salito solo di 0,0,1. Di certo non ci sarà nulla di importante lì dentro. Nella pratica, di solito è vero il contrario. I rilasci di sicurezza del core di WordPress tendono a sembrare piccoli in superficie e a contare molto in profondità. Questo articolo spiega cosa contengono davvero quegli aggiornamenti, perché vengono pubblicati e come applicarli senza rompere il sito.
Come sono numerate le versioni di WordPress
WordPress utilizza un numero di versione in tre parti. Le versioni maggiori aumentano il primo o il secondo numero e introducono nuove funzionalità, modifiche di design e miglioramenti interni significativi. Alcuni esempi sono 6.4, 6.5, 6.6 e così via. Le versioni minori aumentano solo il terzo numero e sono quasi sempre incentrate su sicurezza e manutenzione. Un passaggio da 6.7.1 a 6.7.2 è il team di sicurezza che ti comunica di aver trovato e corretto qualcosa.
Le versioni minori vengono di solito distribuite automaticamente per impostazione predefinita sulla maggior parte dei siti, ma non sempre. Se l’impostazione di aggiornamento automatico è stata disattivata, o se il sito ha una configurazione di hosting insolita, potresti doverle applicare manualmente. Il rischio è che una versione minore non applicata ti lasci esposto a una vulnerabilità già documentata pubblicamente.
Cosa contiene un tipico rilascio di sicurezza
I rilasci di sicurezza di WordPress in genere raggruppano diverse correzioni distinte. Un rilascio rappresentativo potrebbe contenere la correzione di una falla di cross site scripting memorizzato, un’escalation di privilegi in uno specifico ruolo utente, un problema nella REST API in cui utenti non autenticati potevano leggere più informazioni del dovuto, e una correzione nel modo in cui WordPress gestisce una specifica categoria di caricamento file.
Ciascuna presa singolarmente non è catastrofica, ma combinate possono fornire a un aggressore un utile insieme di tasselli. Le correzioni di sicurezza non riguardano sempre l’impedire il controllo totale del sito. A volte impediscono che una piccola falla venga usata come un passaggio all’interno di una catena più ampia.
Perché il team del core di WordPress pubblica i dettagli
Quando WordPress pubblica un aggiornamento di sicurezza, pubblica anche informazioni su ciò che è stato corretto. È un compromesso deliberato. Essendo trasparente, il progetto permette ai proprietari dei siti e agli strumenti di sicurezza di conoscere esattamente il proprio rischio. Lo svantaggio è che anche gli aggressori lo sanno. Entro poche ore da un rilascio, gli scanner automatizzati iniziano a sondare il web pubblico alla ricerca di siti che eseguono ancora la versione precedente.
Ecco perché l’intervallo tra il rilascio e l’aggiornamento sul tuo sito è importante. Più aspetti, più ampia è la finestra in cui una vulnerabilità documentata resta non corretta sul tuo server.
Gli aggiornamenti automatici e quando non bastano
Da WordPress 3.7, gli aggiornamenti di sicurezza minori possono essere applicati automaticamente. Per la maggior parte dei siti semplici, questo è attivo per impostazione predefinita e funziona bene. Il sito recepisce la patch entro poche ore dal rilascio e te ne accorgi solo grazie a una notifica via e-mail.
Ci sono però motivi per cui potrebbe non accadere. Gli aggiornamenti automatici possono essere disattivati nel file wp-config.php o tramite un plugin. Alcuni hosting applicano un proprio calendario di patch e disattivano il meccanismo integrato. Alcuni siti hanno permessi del file system che impediscono a WordPress di scrivere nei propri file del core. Se non sei certo che gli aggiornamenti automatici funzionino sul tuo sito, verificalo. Confronta il numero di versione nel piè di pagina dell’area di amministrazione con l’ultimo rilascio su wordpress.org.
Gli aggiornamenti di versione maggiore e la disciplina dello staging
Le versioni maggiori sono diverse. Contengono nuove funzionalità e modifiche di design e possono cambiare il comportamento in modi a cui alcuni plugin o temi non sono pronti. Lo schema più sicuro è applicare gli aggiornamenti maggiori prima su una copia di staging, scorrere le pagine chiave, l’amministrazione e qualsiasi funzionalità personalizzata, e solo allora portare la modifica in produzione.
Per un sito aziendale, la cadenza consigliata è applicare le versioni maggiori entro uno o due mesi dalla loro disponibilità pubblica, dopo che le patch minori immediatamente successive al rilascio si sono assestate. Questo ti dà il tempo di individuare eventuali rotture nel tuo specifico stack senza restare così indietro da uscire dal supporto.
Cosa succede se resti su una vecchia versione maggiore
Il team di sicurezza di WordPress riporta le correzioni di sicurezza su una manciata di versioni maggiori più vecchie, ma non per sempre. Una volta che una versione esce dalla finestra di supporto, le vulnerabilità scoperte al suo interno non verranno corrette. I siti su quelle versioni diventano esposti in modo permanente, e qualsiasi nuova falla pubblicata contro di loro è un ingresso libero per gli aggressori.
La politica di sicurezza di WordPress in genere supporta la versione maggiore attuale più quella precedente. Tutto ciò che è più vecchio vive sul tempo preso in prestito. Se oggi esegui WordPress 5.qualcosa, sei in quella zona di pericolo.
Il quadro più ampio: core, temi, plugin, PHP
Tenere aggiornato il core di WordPress è solo una parte della storia. La stessa logica si applica al tema attivo, a ogni plugin installato e alla versione di PHP eseguita dal tuo hosting. Ciascuno di questi livelli riceve i propri aggiornamenti di sicurezza, e ciascuno deve essere mantenuto aggiornato.
Un sito che esegue l’ultimo core di WordPress ma una versione di PHP di cinque anni fa è comunque a rischio, perché PHP stesso ha avuto correzioni di sicurezza critiche in quegli anni. Un sito con l’ultimo core e PHP ma con un tema abbandonato è comunque a rischio. L’intero stack deve avanzare insieme.
Una routine pratica di aggiornamento
La routine che applichiamo su tutti i siti WordPress che gestiamo è la seguente. Conferma un backup esterno recente. Applica gli aggiornamenti minori del core non appena compaiono, di solito automaticamente. Applica gli aggiornamenti di plugin e temi almeno settimanalmente, a lotti, in staging per quelli rischiosi. Applica le versioni maggiori del core mensilmente, dopo i test in staging. Rivedi la versione di PHP annualmente, o prima se il tuo hosting annuncia una dismissione. Tieni d’occhio i feed di sicurezza nel caso emerga uno zero day che richieda un intervento fuori ciclo.
Niente di tutto questo è misterioso. È semplicemente disciplina. I siti che finiscono nei guai sono quasi sempre quelli in cui la disciplina è venuta meno, spesso per mesi o anni.
Hai bisogno di aiuto?
Se non sei sicuro che il core del tuo WordPress sia aggiornato, che gli aggiornamenti automatici scattino correttamente o che il tuo sito possa passare in sicurezza all’ultima versione maggiore, Defyn può fare un audit e portare tutto al passo. Mettiti in contatto e riporteremo lo stack in uno stato noto e affidabile.
