Proteggere e migliorare il file WP-CONFIG in WordPress
da Massimo Della Rovere · pubblicato il 28 Dicembre, 2016 · modificato il 5 Giugno, 2017

Dopo diversi anni di esperienza con WordPress sono arrivato alla conclusione che il file WP-CONFIG.php o almeno una parte di configurazione contenuta in esso non debba stare nella directory principale di WordPress. La tecnica che riporterò in questo articolo non è una cosa riconosciuta nell’ambiente WP ma è basata solo sulla mia esperienza e quindi non è detto che possa essere di gradimento a tutti gli utenti.

File di configurazione

Come tutti gli utilizzatori di WordPress sanno, il file wp-config contiene alcune costanti di configurazione, come ad esempio la parte della sicurezza con le informazioni di accesso al database e i token per chiavi di autenticazione. Inoltre troviamo anche altre costanti come ad esempio l’impostazione HTTPS, il prefisso delle tabelle, etc etc.

Tutte queste informazioni non sono solo indispensabili al funzionamento di WP ma sono informazioni molto importanti che riguardano la sicurezza e quindi dobbiamo sempre stare attenti quando facciamo girare questo file per la rete. Purtroppo in molti casi questo non succede, basta pensare ai trasferimenti FTP in chiaro (usatissimi) attraverso connessioni internet assolutamente insicure.

La mia idea di fondo è quella di eliminare queste info dal file wp-config e metterle in un file diverso da includere nel file di configurazione principale, inoltre la posizione del file incluso non deve essere accessibile dal webserver tramite HTTP, quindi fuori dal folder chiamato “public”, per chiarezza vi lascio qui uno schema della struttura.

--> /webserver/public/wp-config.php
@require(dirname(__FILE__).'/../private/configurazione.php');

--> /webserver/private/configurazione.php
define('DB_NAME','database');
define('DB_USER','account');
define('DB_PASSWORD','password');
define('DB_HOST','host');

Questo schema è stato studiato per tutte quelle configurazioni che prevedono una cartella “public” che corrisponda alla root del server web. Nel caso di configurazioni diverse bisogna aggiustare il path in base alle caratteristiche del proprio server.

Comodità e Sicurezza

Adesso che è chiara l’operazione che vi ho consigliato andiamo a vedere alcuni casi per cui sono convinto che in questo modo andiamo ad ottenere una maggiore comodità e sicurezza rispetto al file unico presente nella directory principale di WordPress.

(1) Evitare il trasferimento del file secondario con le credenziali. 

Ad esempio se abbiamo un’ambiente di sviluppo e uno di produzione potremmo fare il trasferimento solo della cartella “public” tra un’ambiente locale a quello remoto senza mai far passare le credenziali per rete, in quanto ogni ambiente ha già il file presente nella sua directory “private” e difficilmente questo cambierà. Inoltre può risultare anche comodo nel caso in cui i due ambienti abbiamo metodi di autenticazione diversi, in questo modo dopo il trasferimento non dobbiamo cambiarli perché già presenti.

(2) Eventuale lettura di wp-config.php non elencherebbe le credenziali.

Ci sono casi molto rari, come ad esempio la disattivazione del modulo PHP o la creazione di file temporanei con estensione swp (causati da editor chiusi male) che potrebbero dare accesso di lettura al sorgente del file di configurazione. Nel nostro caso il pericolo sarebbe ridotto in quanto le info non saranno presenti nel file.

(3) Escludere le credenziali dai file di backup.

Un’altro punto delicato delle credenziali è la loro presenza nei file di backup, la cosa migliore è tenere le credenziali in un posto sicuro e non includere queste informazioni nei molteplici file di salvataggio come ZIP, TAR, etc etc. Utilizzando il mio consiglio potete eseguire i backup partendo dalla cartella public e ignorare la private.

(4) Maggiore elasticità su alcune opzioni di configurazione.

Tenere la definizione di alcune costanti fuori dai file principali di WordPress potrebbe in alcuni casi essere molto comoda. Ad esempio se in locale non ho bisogno di HTTPS, mentre questo è obbligatorio in ambiente di produzione potrei elencare le opzioni per forzare l’accesso HTTPS solo nel file privato presente in produzione.

define('FORCE_SSL_LOGIN',true);
define('FORCE_SSL_ADMIN',true);

In questo modo un’eventuale upload del file wp-config tra i due ambienti non necessita di un secondo intervento manuale per specificare la particolarità. Per lo stesso motivo potrebbe essere utile definire la costante del prefisso di database, in quanto i due ambienti  potrebbero essere uguali sui file PHP ma non sul prefisso di tabella.

Conclusione

Se ritenete valido questo consiglio e volete metterlo in pratica fatemi sapere come vi ci siete trovati e se possibile datemi qualche consiglio per migliorarlo. Prima di chiudere l’articolo vorrei sottolineare di usare bene la specifica di include, infatti utilizzate il comando dirname(__FILE__) per essere sicuri che l’include non sia relativo.

@require(dirname(__FILE__).'/../private/configurazione.php');

Se avete problemi di inclusione e ricevete qualche errore 500 controllate i log di apache o del webserver che utilizzate e verificate se ci sono problemi di permessi sul file. Vi consiglio di dare permessi di sola lettura rispetto all’utente usato dal server web.

2 Commenti

  1. Articolo proprio bello ed interessante. Devo provare. Una domanda (da profano) ma frazionando il file non si rischia di creare un rallentamento nel caricamento del file stesso e quindi anche della risposta del sito?

  2. Ciao Andrea, una funzione di include non incide molto sul tempo di risposta, wordpress stesso prima di caricare tutto il core esegue decine di include, senza contare che nella modalitá ad oggetti con autoload ogni classe è di fatto una include. Per avere il problema di andare a contare un millessimo di secondo di una include bisogna aver un sito ultra perfetto.

condividi