Un articolo apparso su WP Tuts offre una superficiale introduzione al tema della sicurezza in WordPress. In questo articolo vorrei approfondire questa tematica.
Plugin e temi: porte spalancate al nemico
Se leggete l'elenco delle vulnerabilità relative a WordPress sul sito Secunia, noterete come più del 95% di queste vulnerabilità riguarda plugin e temi.
Un plugin (o un tema) è potenzialmente pericoloso per la sicurezza, ma lo è ancor di più se:
- accetta l'input dell'utente (POST o GET)
- interagisce con il database (query personalizzate)
- interagisce con il file system
Purtroppo queste caratteristiche non esauriscono la casistica delle potenziali vulnerabilità: in generale sono pericolosi quei plugin o temi che non vengono aggiornati con regolarità o, peggio ancora, vengono rilasciati e mai più aggiornati.
Non basta disabilitare un plugin o un tema per rimuovere una potenziale falla: tutti i file vanno rimossi al fine che questi non possano più essere accessibili da remoto.
La regola d'oro è quella di usare pochi plugin ma soprattutto plugin di cui si è sperimentata l'affidabilità e la frequenza degli aggiornamenti. Tutti gli altri vanno rimossi senza indugio.
Per i temi vale la stessa cosa: in questo caso cambiare tema è un ulteriore soluzione.
admin? No grazie!
Per impostazione predefinita WordPress crea un profilo amministrativo il cui username è admin. Se avete installato il plugin Limit Login Attempts contro gli attacchi brute force avrete sicuramente notato come quasi tutti i tentativi utilizzino questo username come nome utente.
Il profilo va rimosso e sostituito con un nuovo account amministrativo.
Username e password sicuri
Sicuri? Io direi piuttosto difficili da indovinare o che almeno richiedano molto tempo da parte dei tool a disposizione di un attacker per essere scoperti. Quindi:
- non usate un nome utente che possa essere rintracciato, come ad esempio dall'URL della vostra pagina autore o dal vostro indirizzo e-mail
- usate password random (caratteri alfanumerici e simboli) con una lunghezza minima di 32 caratteri (alcuni consigliano 8 o 13 caratteri ma melius abundare quam deficere)
- cambiate la vostra password con regolarità (almeno una volta al mese)
- se avete più di un sito, non usate la stessa password su tutti i siti
Usare SSL nella parte amministrativa
WordPress permette di abilitare SSL nella parte amministrativa attraverso il file wp-config.php:
define('FORCE_SSL_ADMIN', true);
Potete trovare maggiori informazioni nella documentazione ufficiale.
Usare prefissi sicuri per le tabelle del database
Il prefisso predefinito delle tabelle del database di WordPress è wp_. Ciò significa che se un attacker ha accesso al database può facilmente eseguire operazioni sulle tabelle.
Possiamo definire un prefisso diverso nel file wp-config.php:
$table_prefix = 'fVjU_';
Chiavi di autenticazione
Visitando l'indirizzo https://api.wordpress.org/secret-key/1.1/salt/ possiamo generare le nostre chiavi di autenticazione che andranno sostituite a quelle predefinite (vuote) nel file wp-config.php:
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
define('AUTH_SALT', 'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT', 'put your unique phrase here');
define('NONCE_SALT', 'put your unique phrase here');
Aggiornamenti di WordPress
WordPress deve essere sempre aggiornato. Tutto qui.
FTP sicuro
Dovreste sempre usare SSL nei trasferimenti FTP qualora questo sia disponibile. Inoltre dovreste sempre verificare che il vostro computer non sia infetto da malware.
Server al sicuro
Prima di sottoscrivere un qualsiasi contratto di hosting dovreste sempre (sempre!) verificare che nel contratto sia compresa la manutenzione ed il monitoraggio del server.
Tutto quanto abbiamo detto in precedenza non ha alcun senso se un attacker ha accesso al server. Da li può fare qualsiasi cosa. Certo, l'assistenza costa ed il supporto anche.
Se siete anche sistemisti, potreste certamente fare da soli. Ma se non lo siete, sappiate che se succede qualcosa e non avete supporto siete in un mare di guai. Letteralmente.
Il vostro server potrebbe ad esempio essere utilizzato per il phishing o lo spam. Di conseguenza verrete bollati come tali da tutti gli altri servizi presenti sul Web. In pratica le uniche e-mail che non vi verranno respinte saranno quelle che vi autoinvierete.
Questo va detto: sembra duro da accettare, ma la realtà è questa.