Disabilitare il debug
La funzionalità di debug non dovrebbe essere attiva in ambienti di produzione, dato che potrebbe fornire informazioni utili a potenziali hacker.
define( 'WP_DEBUG', false );
#if WP_DEBUG_LOG is enabled, you have to enable WP_DEBUG as well
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Le informazioni di debug sono molto utili mentre si sviluppa un’applicazione WordPress. Tuttavia, è importante che tale parametro sia impostato nuovamente su “false” prima di caricare il sistema su un server online. Gli errori dovrebbero essere tracciati, ma mai esposti ad utenti non autorizzati.
Utilizzare credenziali database robuste
Ogni installazione di WordPress dovrebbe avere il proprio database con un utente dedicato ed una password sicura ed univoca.
define( 'DB_NAME', 'unique_database_name' );
define( 'DB_USER', 'unique_database_user' );
define( 'DB_PASSWORD', 'strong_and_unique_password' );Quando si installa WordPress, può essere specificato un prefisso per le tabelle. Ciò consentirebbe l’esecuzione di più installazioni di WordPress sullo stesso database. Tuttavia, condividere un database tra diverse installazioni è pericoloso perché, se un’instanza viene attaccata, anche le altre installazioni sono a rischio. Inoltre, si dovrebbe evitare l’utilizzo di un account root sul database, poiché ha accesso completo a tutti i database sul server.
Utilizzare chiavi e “sali” unici
I “sali” e le chiavi dovrebbero essere uniche per ciascuna installazione di WordPress, dato che questo è l’unico modo di assicurare una gestione utenti sicura.
#These values are intentionally left blank to avoid copy-pastes
define( 'AUTH_KEY', '' );
define( 'SECURE_AUTH_KEY', '' );
define( 'LOGGED_IN_KEY', '' );
define( 'NONCE_KEY', '' );
define( 'AUTH_SALT', '' );
define( 'SECURE_AUTH_SALT', '' );
define( 'LOGGED_IN_SALT', '' );
define( 'NONCE_SALT', '' );I sali e le chiavi sono importanti per una serie di funzionalità in WordPress. Tra le altre cose, consentono una gestione sicura di sessioni e login.
I valori sono automaticamente scelti in modo casuale durante l’installazione. Tuttavia, una installazione di WordPress potrebbe essere duplicata. Durante il deploy, è altamente raccomandato di generare nuovi valori per queste costanti. Questi valori possono essere generati attraverso le API accessibili dal link seguente:
https://api.wordpress.org/secret-key/1.1/salt/
Utilizzare crittografia SSL
Nessuno dovrebbe avere la possibilità di intercettare e sniffare il traffico tra l’utente ed il server. Utilizzare la crittografia SSL e forzare WordPress per utilizzare solo questo tipo di connessione.
define( 'WP_SITEURL', 'https://www.mydomain.com' );
define( 'WP_HOME', 'https://www.mydomain.com' );
define( 'FORCE_SSL_ADMIN', true );
define( 'FORCE_SSL_LOGIN',true );È ora una pratica comune quella di crittografare il traffico. La quasi totalità dei browser contrassegna le connessioni non-crittografate come pericolose e non sicure. Molto spesso i fornitori di hosting offrono ai propri clienti certificati SSL gratuiti per abilitare la crittografia SSL, come quelli proposti da Let’s Encrypt.
Proibire la riparazione del database
WordPress supporta la riparazione automatica del database. Ciò non dovrebbe essere possibile senza un backup preventivo del database.
define( 'WP_ALLOW_REPAIR', false );Il percorso wp-admin/maint/repair.php, accessibile anche ad utenti non autenticati avvia questo processo automatico. Questo potrebbe essere molto utile in caso di malfunzionamenti o danneggiamenti del database. Tuttavia, il processo non dovrebbe mai essere lanciato senza prima aver eseguito un backup del database.
Disabilitare il contenuto non filtrato
Gli Admin e gli Editor possono pubblicare HTML non filtrato o file. Se ciò non è strettamente necessario, si raccomanda di attivare i filtri seguenti:
define( 'DISALLOW_UNFILTERED_HTML', true );
define( 'ALLOW_UNFILTERED_UPLOADS', false );Per impostazione predefinita, gli Admin e gli Editor possono scrivere HTML non filtrato in titoli, contenuto e commenti dei post. Il filtro sui tipi dei file possono anche essere disattivati. Questi filtri dovrebbero rimanere attivati.
Abilitare gli aggiornamenti di sicurezza automatici
Un’installazione di WordPress dovrebbe essere sempre aggiornata per poter fronteggiare gli ultimi attacchi. Attivare gli aggiornamenti automatici per i rilasci di sicurezza.
define( 'AUTOMATIC_UPDATER_DISABLED', false );
define( 'WP_AUTO_UPDATE_CORE', 'minor' );Dato che WordPress è uno dei CMS più utilizzati al mondo, molti hacker provano a sfruttare le vulnerabilità note nelle installazioni obsolete. Si raccomanda di eseguire un backup completo prima di ogni upgrade del core, pertanto solo gli aggiornamenti “minor” contenenti delle patch di sicurezza dovrebbero essere installati automaticamente.
https://codex.wordpress.org/Configuring_Automatic_Background_Updates
Bloccare richieste esterne
L’accesso dall’installazione WordPress a risorse esterne dovrebbe essere ristretto. È consigliato di accettare solo risorse fidate.
define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,
*.github.com, www.trusteddomain.com' );Non si dovrebbero controllare esclusivamente gli accessi a WordPress dall’esterno, ma anche quelli dal sistema verso risorse esterne. Applicare quindi il principio delle white-list invece delle black-list.
Disabilitare le modifiche ai file
Probire la modifica delle linee di codice nei plugin e nei temi da parte di amministratori ed editor. Disattivare l’editor di file per tutte le estensioni.
define( 'DISALLOW_FILE_EDIT', true );Manipolando il codice, un’estensione affidabile potrebbe diventare un veicolo per gli attacchi.
Disabilitare la modifica del sistema
Per rinforzare ulteriormente un’installazione di WordPress è possibile prevenire qualsiasi modifica al sistema proibendo l’installazione di plugin e temi.
define( 'DISALLOW_FILE_MODS', true );I temi ed i plugin non portano solo vantaggi e benefici ad un’installazione di WordPress. È necessario potersi fidare degli sviluppatori di queste estensioni. Attivando questa “barriera” sarà possibile impedire ad amministratori ed editor di caricare ed installare estensioni non affidabili
Traduzione dello studio svolto da RipsTech: “WordPress Configuration Cheat Sheet“.
Hosting Ottimizzato per WordPress
In Host abbiamo sempre dato molta importanza alla compatibilità e all’ottimizzazione dei nostri profili di Hosting con i più diffusi CMS. I nostri Hosting includono accesso SSH e WP_CLI così da poter gestire tutti gli aspetti del tuo sito WordPress. Inclusi, inoltre, Certificato SSL e HTTP/2 per garantirti sicurezza e performance.
