Quando la maggior parte delle persone immagina la violazione di un sito web, si raffigura qualcuno con il cappuccio che digita freneticamente a un terminale. La realt\u00e0 \u00e8 molto meno drammatica e molto pi\u00f9 comune. I siti WordPress vengono compromessi ogni giorno da scanner automatizzati che scandagliano il web pubblico, sondano migliaia di siti alla volta ed entrano da porte lasciate aperte. L’aggressore di solito \u00e8 uno script, non una persona, e l’obiettivo raramente sei proprio tu. \u00c8 chiunque si trovi a far girare il software che sanno sfruttare.<\/p>\n
Capire i veri punti d’ingresso conta, perch\u00e9 lo stesso pugno di errori spiega la stragrande maggioranza delle violazioni di WordPress. Correggili e diventi un bersaglio molto pi\u00f9 difficile. Ignorali e stai andando avanti a fortuna.<\/p>\n
I plugin sono la causa numero uno delle compromissioni di WordPress. L’ecosistema dei plugin \u00e8 enorme e la qualit\u00e0 del codice \u00e8 disomogenea. Un plugin perfettamente sicuro due anni fa pu\u00f2 vedersi pubblicare una vulnerabilit\u00e0 critica la settimana prossima, e se non lo hai aggiornato, sei esposto nel momento in cui quell’avviso diventa pubblico.<\/p>\n
Lo schema di solito \u00e8 questo. Un ricercatore o un malintenzionato scopre una falla in un plugin popolare, spesso qualcosa come un caricamento di file senza autenticazione o una SQL injection. La falla viene divulgata. Entro poche ore, gli scanner automatizzati setacciano internet cercando siti che eseguono la versione vulnerabile. I siti non corretti vengono compromessi in massa.<\/p>\n
Un audit recente che abbiamo svolto sul sito di un’agenzia di Sydney ha rivelato un plugin file manager rimasto installato e attivo per oltre un anno, nonostante quella famiglia di plugin avesse una lunga storia di vulnerabilit\u00e0 di esecuzione di codice da remoto. L’aggressore non ha dovuto fare nulla di astuto. Il plugin gli ha consegnato l’accesso in scrittura all’intero sito.<\/p>\n
Gli attacchi di forza bruta contro la pagina di accesso di WordPress sono costanti. I bot provano migliaia di combinazioni comuni di nome utente e password all’ora, attingendo da database di violazioni che contengono centinaia di milioni di credenziali trapelate. Se il tuo amministratore usa un nome utente come admin, il nome della tua azienda o il tuo nome di battesimo, e una password apparsa in una qualsiasi violazione passata da qualche parte su internet, sei gi\u00e0 nella lista.<\/p>\n
La soluzione non \u00e8 complicata. Usa password uniche e lunghe. Usa un gestore di password. Usa l’autenticazione a due fattori su ogni account amministratore. Limita i tentativi di accesso. Rinomina il tuo utente amministratore predefinito in qualcosa di non indovinabile. Questi passaggi sono noiosi e bloccano sul nascere la maggior parte degli attacchi automatizzati.<\/p>\n
Il core di WordPress in s\u00e9 \u00e8 generalmente ben mantenuto, con versioni di sicurezza distribuite rapidamente. Il rischio non \u00e8 che il core sia pieno di falle. Il rischio \u00e8 che alcuni proprietari di siti disattivino gli aggiornamenti automatici e poi si dimentichino di applicare quelli manuali. Eseguire una versione di WordPress vecchia di uno o due anni significa funzionare con vulnerabilit\u00e0 documentate pubblicamente che qualsiasi scanner pu\u00f2 rilevare.<\/p>\n
WordPress ti avvisa quando \u00e8 disponibile un aggiornamento. Applicalo. Se temi la compatibilit\u00e0 dei plugin, applicalo prima su una copia di staging. Non lasciarlo in sospeso.<\/p>\n
Anche i temi sono codice e presentano gli stessi rischi dei plugin. Il problema maggiore sono i temi piratati scaricati da siti loschi. Una copia gratuita di un tema premium da un sito di torrent \u00e8 quasi sempre infarcita di backdoor, link nascosti o peggio. Il risparmio su un tema da cento dollari pu\u00f2 costare migliaia in bonifica.<\/p>\n
Attieniti a temi del repository ufficiale di WordPress o di fornitori affidabili con supporto attivo e aggiornamenti regolari. Paga per ci\u00f2 che usi. \u00c8 molto pi\u00f9 economico dell’alternativa.<\/p>\n
Un numero sorprendente di siti WordPress lascia trapelare file sensibili che non avrebbero mai dovuto trovarsi sul web pubblico. Archivi di backup nella radice del documento, dump .sql, file .env e vecchie copie di wp-config.php con nomi tipo wp-config.bak. Una volta che un aggressore scarica uno di questi, ha le credenziali del database, le chiavi segrete, o entrambe.<\/p>\n
Esamina la radice del documento. Tutto ci\u00f2 che non fa parte di WordPress non dovrebbe essere l\u00ec. Sposta i backup fuori dal server. Elimina i vecchi file di sviluppo. Blocca l’accesso diretto ai nomi di file sensibili comuni a livello di server.<\/p>\n
Sull’hosting condiviso economico, pi\u00f9 siti WordPress possono risiedere sullo stesso account o persino sullo stesso disco. Se uno di essi viene compromesso, l’aggressore ha spesso la capacit\u00e0 di spostarsi sugli altri, depositando lo stesso malware su ogni sito del gruppo. \u00c8 uno schema comune nelle agenzie che gestiscono venti o trenta siti di clienti su un unico piano condiviso.<\/p>\n
Isola i siti. Usa un vero hosting WordPress gestito in cui ogni sito risiede nel proprio contenitore. Esamina qualsiasi altro sito che condivide il tuo ambiente con lo stesso rigore del tuo.<\/p>\n
WordPress espone due interfacce programmatiche principali, xmlrpc.php e la REST API. Entrambe sono legittime, entrambe possono essere utili ed entrambe sono state usate come vettori d’attacco. XML-RPC in particolare \u00e8 stato storicamente abusato per attacchi di forza bruta amplificati, in cui una singola richiesta pu\u00f2 tentare molte ipotesi di password contemporaneamente.<\/p>\n
Se non usi XML-RPC, disattivalo. Se non ti serve l’accesso non autenticato della REST API a determinati endpoint, limitalo. La maggior parte degli hosting moderni e dei plugin di sicurezza rende tutto questo semplice.<\/p>\n
Un aggressore non sempre ha bisogno della tua password. Se riesce a catturare un cookie di sessione, ad esempio tramite un attacco man in the middle su una connessione non sicura, pu\u00f2 impersonarti per tutto il tempo in cui quella sessione resta valida. Accedere su un wifi pubblico senza VPN, o gestire un sito senza un HTTPS adeguato ovunque, rende tutto molto pi\u00f9 facile.<\/p>\n
Usa sempre HTTPS. Forzalo sull’intero sito. Imposta i flag dei cookie sicuri. Esci quando hai finito. Ruota periodicamente i salt e le chiavi di WordPress in modo che le sessioni esistenti vengano invalidate.<\/p>\n
Alcune compromissioni non richiedono alcuna falla software. Un’e-mail di phishing che chiede a un dipendente di accedere a una falsa pagina di amministrazione, una falsa e-mail con fattura che induce uno sviluppatore a eseguire un comando shell ostile, un collaboratore che riutilizza la stessa password ovunque e poi se la vede trapelare da qualche altra parte. Le persone fanno parte della superficie d’attacco.<\/p>\n
Forma il personale. Usa un gestore di password in tutto il team. Imponi l’autenticazione a due fattori. Limita il numero di account con accesso di livello amministratore. Rimuovi gli account nel momento in cui qualcuno lascia il progetto.<\/p>\n
Molti siti WordPress vengono lanciati per una campagna, un evento o un progetto secondario, e poi dimenticati. Continuano a girare sullo stesso hosting, con le stesse credenziali, scivolando lentamente nell’obsolescenza. Un anno dopo sono un bersaglio perfetto. Il proprietario ha smesso di controllarli, ma Google e i bot no.<\/p>\n
Se non ti serve pi\u00f9 un sito WordPress, mettilo offline come si deve. Esporta i contenuti, smantella l’installazione, libera il dominio, archivia il database. Non lasciare installazioni abbandonate sull’internet pubblico.<\/p>\n
Le difese non sono esotiche. Tieni tutto aggiornato. Usa password forti e uniche pi\u00f9 l’autenticazione a due fattori. Esegui un plugin di sicurezza serio come Wordfence e presta attenzione a ci\u00f2 che ti dice. Assicurati che il tuo hosting sia affidabile, isoli correttamente i siti e offra backup esterni. Esamina plugin, temi e utenti amministratori almeno trimestralmente. Ruota chiavi e salt quando cambiano dipendenti o collaboratori. Ripristina da un backup ogni tanto, solo per sapere che funziona.<\/p>\n
Niente di tutto questo \u00e8 affascinante. \u00c8 routine e funziona. I siti che vengono compromessi non sono quasi mai quelli che hanno fatto tutto questo. Sono quelli che ne hanno fatto la maggior parte, o niente, dando per scontato di essere troppo piccoli per essere notati.<\/p>\n