In ogni sito dinamico c’è un file che conta più degli altri: quello di configurazione. In WordPress si chiama wp-config.php, in PrestaShop è app/config/parameters.php (nelle versioni 1.7 e successive) o config/settings.inc.php (nella 1.6). Dentro ci sono i dati per collegarsi al database e le chiavi segrete del sito. Chi riesce a leggerlo ha in mano buona parte del sito. Vediamo cosa contiene, come si espone per errore e come proteggerlo.
Cosa c’è in un file di configurazione
Anche se ogni CMS ha il suo formato, il contenuto è simile:
- nome del database, utente e password con cui il sito si collega;
- chiavi e «sali» segreti, usati per proteggere sessioni, cookie e, in alcuni casi, dati cifrati;
- impostazioni come il prefisso delle tabelle, la modalità di debug, a volte credenziali di servizi esterni (posta, pagamenti, cache).
Con questi dati, chi attacca può leggere e modificare il database, creare amministratori, e in certi casi impersonare utenti già collegati.
Come si espone un file di configurazione
Normalmente il file non è leggibile da un visitatore: il server lo esegue come codice e non ne mostra il contenuto. I problemi nascono quasi sempre da copie e versioni dimenticate:
- copie di sicurezza create a mano con un’estensione diversa, del tipo «vecchio», «backup», «copia»: il server non le esegue più come codice e può mostrarle come semplice testo;
- file temporanei lasciati dagli editor durante una modifica;
- archivi del sito (zip, dump del database) lasciati nella cartella pubblica dopo una migrazione;
- cartelle di versionamento, come quella di Git, pubblicate insieme al sito;
- la modalità di debug lasciata accesa, che può mostrare percorsi e dettagli negli errori.
Gli scanner automatici cercano proprio questi file dimenticati: è una delle prime cose che provano su qualsiasi sito.
Come proteggerlo
1. Niente copie nella cartella pubblica
È la regola più importante. Se devi fare una copia del file di configurazione prima di modificarlo, scaricala sul tuo computer, non lasciarla nel sito. Lo stesso vale per archivi e dump: dopo averli usati, toglili da public_html. Tieni presente che gli archivi (.zip, .gz, .sql e simili) sono esclusi dai backup automatici, quindi lasciarli lì non serve nemmeno come copia di riserva.
2. Debug spento in produzione
In WordPress la modalità di debug si controlla dal file di configurazione; in PrestaShop dalle impostazioni di prestazioni o, nelle versioni recenti, dal file di configurazione. Usala solo per il tempo strettamente necessario e, se ti serve il registro degli errori, fai in modo che finisca in un file e non sullo schermo dei visitatori.
3. Permessi restrittivi
Il file di configurazione deve poter essere letto dal sito, ma non serve che sia scrivibile da chiunque. Dal file manager del pannello o dal client FTP puoi impostare permessi più stretti di quelli dei normali file: valori come 640 o 600 vanno bene nella maggior parte dei casi. Dopo averli cambiati, verifica che il sito funzioni; se smette di aprirsi, torna al valore precedente e chiedici aiuto.
4. Password del database robusta e non riutilizzata
La password del database la usa solo il sito, non devi ricordarla: può essere lunga e casuale. Se la cambi dal pannello, ricordati di aggiornarla subito anche nel file di configurazione, altrimenti il sito non riesce più a collegarsi al database.
5. Rigenera le chiavi dopo un incidente
In WordPress le chiavi e i sali si possono sostituire con valori nuovi: l’effetto è che tutti gli utenti collegati vengono disconnessi, compreso chi fosse entrato con una sessione rubata. È un passo utile dopo una violazione o dopo aver tolto l’accesso a un collaboratore. In PrestaShop alcune chiavi servono anche a cifrare dati: non cambiarle senza sapere cosa comportano, e in caso di dubbio chiedi a chi ha sviluppato il negozio.
6. Non condividerlo
Il file di configurazione non va mandato per email, incollato in una chat o in un forum per chiedere aiuto. Se devi mostrarlo a qualcuno, togli prima password e chiavi. Se ci apri un ticket, non serve che ce lo invii: lo leggiamo noi direttamente sul server, se necessario.
7. Attenzione agli altri file sensibili
Lo stesso ragionamento vale per .htaccess, per i file .env usati da alcune applicazioni, per i file di configurazione di plugin e moduli che contengono chiavi di servizi esterni (corrieri, pagamenti, newsletter). Trattali come password.
Un rapido controllo
| Domanda | Risposta giusta |
|---|---|
Ci sono copie del file di configurazione in public_html? |
No |
| Ci sono archivi o dump del database nella cartella del sito? | No, oppure solo il tempo necessario |
| La modalità di debug è accesa? | No |
| La password del database è usata anche altrove? | No |
| Il file è stato inviato per email o in chat? | No, o le credenziali sono state cambiate dopo |
Cosa facciamo noi
Security Intelligence blocca chi prova a leggere file riservati e protegge i file del sito dalle modifiche non autorizzate. Il firewall di cPGuard ferma gli scanner che cercano punti deboli, e le sue scansioni controllano file e database in cerca di codice malevolo. Gli account FTP sono confinati nella cartella del proprio dominio. Ma la difesa più semplice resta tua: non lasciare copie, archivi e debug a disposizione di chi passa.
In sintesi
- Il file di configurazione contiene le chiavi del sito: database e segreti.
- Si espone quasi sempre per copie, archivi e debug dimenticati.
- Niente copie in
public_html, debug spento, permessi stretti, password del database unica. - Dopo un incidente, cambia la password del database e rigenera le chiavi.