Proteggere il file di log di debug di WordPress

Quando il debug di WordPress è abilitato, errori e avvisi vengono scritti in un file di log su /wp-content/debug.log. Questo è incredibilmente utile durante lo sviluppo. Su un sito di produzione, tuttavia, un log di debug accessibile pubblicamente è un grave rischio per la sicurezza. Chiunque conosca l'URL può leggerlo e spesso contiene informazioni molto più sensibili di quanto la maggior parte dei proprietari di siti si renda conto.

Cosa contiene il log di debug

Il file debug.log non è solo un elenco di avvisi PHP. A seconda della configurazione del tuo sito e dei plugin che utilizzi, può contenere:

• Errori e avvisi PHP: questi contengono percorsi di file, numeri di riga e nomi di funzione. Un aggressore può utilizzare queste informazioni per mappare la struttura delle directory del tuo server e identificare codice vulnerabile.
• Errori delle query del database: le query fallite a volte contengono nomi di tabelle, nomi di colonne e persino frammenti dei dati interrogati. Questo dà agli aggressori una visione dello schema del tuo database.
• Errori di plugin e temi con stack trace: gli stack trace rivelano quali plugin utilizzi, le loro versioni e come interagiscono. Questo è prezioso per pianificare attacchi mirati contro vulnerabilità note dei plugin.
• Chiavi API e credenziali: plugin scritti male a volte registrano risposte API o errori di connessione contenenti token di autenticazione, chiavi API o persino password in chiaro.
• Dati utente e indirizzi email: errori relativi alla registrazione utente, invio di moduli o invio di email possono contenere dati personali come nomi, indirizzi email e input del modulo.
• Percorsi del filesystem: ogni errore PHP contiene il percorso completo del server al file in cui si è verificato l'errore. Questo rivela la struttura delle directory di hosting, il nome utente e talvolta il tuo provider di hosting.

Perché il log di debug è accessibile pubblicamente

Per impostazione predefinita, WordPress salva debug.log nella directory wp-content. Questa directory viene servita dal tuo server web come qualsiasi altra cartella nella tua installazione WordPress. A meno che tu non abbia specificamente bloccato l'accesso, chiunque può digitare https://tuosito.it/wp-content/debug.log in un browser e leggere il file.

Molti provider di hosting non bloccano questo percorso per impostazione predefinita. E poiché il file cresce nel tempo senza rotazione automatica, può accumulare mesi o addirittura anni di dati di errore sensibili.

Come gli aggressori trovano i log di debug

Gli scanner automatizzati controllano sistematicamente /wp-content/debug.log su ogni sito WordPress che incontrano. È uno dei primi percorsi che gli strumenti di scansione della sicurezza testano. Alcuni aggressori controllano anche varianti comuni:

• /wp-content/debug.log (posizione predefinita)
• /debug.log (a volte configurato in modo errato)
• /wp-content/uploads/debug.log (un'altra configurazione errata comune)
• /error_log o /error.log (nomi generici per i log degli errori)

Queste scansioni sono economiche, veloci e completamente automatizzate. Se il tuo log di debug è accessibile, verrà trovato.

Bloccare l'accesso con .htaccess (Apache)

Se il tuo server funziona su Apache, aggiungi questa regola al file .htaccess nella tua directory wp-content:

    Order allow,deny
    Deny from all

Questo dice ad Apache di rifiutare tutte le richieste HTTP per il file debug.log. Il file esiste ancora su disco e PHP può ancora scriverci, ma nessuno può scaricarlo tramite un browser. Se vuoi bloccare tutti i file di log per precauzione, puoi usare una regola più ampia:

    Order allow,deny
    Deny from all

Bloccare l'accesso con Nginx

Per i server Nginx, aggiungi questo blocco location alla tua configurazione del server:

location ~* /debug\.log$ {
    deny all;
    return 404;
}

Restituire un 404 invece di un 403 è una scelta deliberata. Una risposta 403 (Forbidden) dice a un aggressore che il file esiste ma è protetto. Un 404 (Not Found) non rivela nulla. Dopo aver aggiunto questa regola, ricarica la configurazione Nginx con sudo nginx -s reload.

Sposta il file di log al di fuori della webroot

L'approccio più sicuro è memorizzare il log di debug in una directory che il tuo server web non può servire affatto. Nel tuo wp-config.php, imposta la costante WP_DEBUG_LOG su un percorso assoluto al di fuori della tua webroot:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/home/tuoutente/logs/wp-debug.log');
define('WP_DEBUG_DISPLAY', false);

La directory /home/tuoutente/logs/ deve esistere ed essere scrivibile dal processo del server web. Impostare WP_DEBUG_DISPLAY su false è altrettanto importante: impedisce che gli errori PHP vengano mostrati direttamente sulle tue pagine, dove i visitatori (e gli aggressori) potrebbero vederli.

Disabilita la modalità debug sui siti di produzione

Su un sito di produzione live, il debug dovrebbe essere quasi sempre disabilitato. Raramente c'è una buona ragione per lasciarlo abilitato in modo permanente. Imposta questi valori in wp-config.php:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

Se devi eseguire il debug di un problema in produzione, abilita temporaneamente la modalità debug, riproduci il problema, controlla il log e disabilitalo subito dopo. Non lasciare mai il debug abilitato "per ogni evenienza". Il rischio non vale la comodità.

Monitora la dimensione del file di log di debug

Se mantieni il debug abilitato su un sito di staging o di sviluppo, monitora la dimensione del log di debug. Senza la rotazione dei log, può crescere fino a centinaia di megabyte e alla fine riempire il tuo disco. Considera di impostare un cronjob per ruotarlo o troncarlo:

# Rotate debug.log weekly, keep 4 backups
# Add to /etc/logrotate.d/wp-debug
/home/tuoutente/logs/wp-debug.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

Cosa fare se dati sensibili sono già stati esposti

Se il tuo log di debug era accessibile pubblicamente e conteneva informazioni sensibili, esegui immediatamente questi passaggi:

• Elimina il file del log di debug: rimuovilo immediatamente dal server.
• Ruota tutte le chiavi API e le credenziali: ogni chiave API, password o token apparso nel log deve essere considerato compromesso. Rigeneralo.
• Cambia le password del database: se sono stati registrati errori di connessione al database, le credenziali potrebbero essere state esposte.
• Controlla l'accesso non autorizzato: rivedi i log di accesso del tuo server per le richieste a debug.log. Se qualcuno l'ha scaricato, valuta quali informazioni ha ottenuto.
• Notifica gli utenti interessati: se sono stati registrati dati personali (email, nomi, invii di moduli), potresti avere un obbligo GDPR o di privacy di informare le persone interessate.

Verifica con InspectWP

InspectWP controlla se /wp-content/debug.log è accessibile pubblicamente sul tuo sito. Dopo aver protetto il file (bloccando l'accesso, spostandolo o disabilitando la modalità debug), esegui una nuova scansione InspectWP. La sezione sicurezza del report conferma se il file è ancora raggiungibile. Se l'avviso persiste, cancella eventuali cache lato server e verifica che le tue regole .htaccess o Nginx vengano applicate alla directory corretta.