Loggare in sicurezza: registrare gli errori senza fuga di dati

In breve: il logging in PHP con attenzione alla privacy significa: registrare per intero gli eventi rilevanti per la sicurezza, ma non scrivere mai nel log password, token, identificatori di sessione e dati sensibili dei clienti. Gli errori vanno nel registro, non sullo schermo, i log stanno fuori dal webroot e sono protetti da modifiche. Per quanto tempo i log restino lo decide consapevolmente insieme al responsabile della protezione dei dati.

Tra raccolta di tracce e fuga di dati

Dopo PHP2Shell i media specializzati hanno consigliato di conservare i log del server web dal 20/10/2026. Chi voleva attuarlo constatava spesso due cose. O i log erano stati da tempo ruotati e cancellati. Oppure contenevano cose che non avrebbero mai dovuto starci: contenuti completi di moduli, password di accessi falliti, chiavi API negli URL.

Entrambe le cose sono un problema. Senza log un incidente si ricostruisce a fatica. Con troppo contenuto il log stesso diventa un bersaglio, perché chi ottiene accesso al server lo legge volentieri. Un buon logging sta nel mezzo: abbastanza per la ricerca delle tracce, il meno possibile di dati da proteggere.

Che cosa dovrebbe registrare un'applicazione PHP

Il Logging Cheat Sheet OWASP indica gli eventi che contano per sicurezza e tracciabilità. Per le tipiche applicazioni PHP si possono riassumere così:

Ogni voce dovrebbe rispondere alle domande quando, dove, chi e che cosa: marca temporale, applicazione e host, indirizzo di origine, identificativo utente, tipo di evento ed esito. Nomi o indirizzi e-mail si possono spesso mascherare o sostituire con un identificativo interno, senza perdere utilità.

Due fonti di dati indesiderati nel log si trascurano spesso. La prima sono gli URL: se un token, una chiave di reset della password o un indirizzo e-mail si trova nella query string, finisce automaticamente nel log di accesso del server web, nei log dei proxy e nella cronologia del browser. Tali valori appartengono al body della richiesta o a un header, non all'indirizzo. La seconda fonte è la modalità debug. Framework e plugin in esercizio debug scrivono spesso richieste complete, query al database e variabili d'ambiente. Se questa modalità resta attiva dopo una ricerca di errori, cresce senza che nessuno se ne accorga un file con proprio le informazioni che un aggressore cerca. Dopo ogni ricerca di errori verifichi se gli output di debug sono di nuovo disattivati e cancelli i file generati.

Logging in PHP: le impostazioni di base

Il primo livello è PHP stesso. In produzione gli errori devono essere registrati, ma non emessi. Il log sta fuori dal webroot, in modo da non essere richiamabile tramite un URL.

; php.ini o pool FPM per la produzione
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log

Perché gli errori visibili siano pericolosi lo descrive Disattivare l'output degli errori in produzione. Come errori ed eccezioni siano collegati in PHP lo spiega Errori ed eccezioni in PHP.

Il secondo livello è l'applicazione. Molti framework usano a tal fine una libreria conforme allo standard PSR-3 della PHP-FIG, che definisce un'interfaccia di logger uniforme. Conta non la libreria, ma la disciplina: scegliere consapevolmente i dati di contesto, anziché scrivere nel log richieste o oggetti interi.

<?php
// Disinnescare e mascherare gli input prima di scriverli nel log
function logSicher(string $text): string {
    return mb_substr(str_replace(["\r", "\n"], ' ', $text), 0, 200);
}

function maskiereMail(string $mail): string {
    [$name, $domain] = array_pad(explode('@', $mail, 2), 2, '');
    return mb_substr($name, 0, 1) . '***@' . $domain;
}

$logger->warning('Anmeldung fehlgeschlagen', [
    'benutzer' => maskiereMail(logSicher($_POST['email'] ?? '')),
    'ip'       => $_SERVER['REMOTE_ADDR'] ?? '',
    // mai: 'passwort' => $_POST['passwort']
]);

Log injection e voci manipolate

Se un'applicazione scrive input senza filtro nel log, un aggressore può generare con degli a capo voci falsificate. Ciò confonde l'analisi e può occultare tracce. Il Cheat Sheet OWASP raccomanda formati strutturati come JSON, la rimozione o la codifica degli a capo e un limite di lunghezza per gli input nel log.

Altrettanto importante è la protezione dei log stessi:

1. Collocazione fuori dal webroot e con permessi che l'utente del server web richiede per scrivere, ma non per cancellare vecchi file.
2. Copia su un secondo sistema, ad esempio via Syslog su una connessione cifrata. Chi prende il controllo del server non deve poter cancellare semplicemente le tracce.
3. Limitare l'accesso in lettura e registrarlo a sua volta. I log contengono quasi sempre dati personali.
4. Riconoscere l'interruzione: se il log all'improvviso resta vuoto, è un segnale d'allarme.
5. Allineare l'ora: tutti i server prendono l'ora dalla stessa fonte e scrivono nel log un fuso orario univoco. Altrimenti, dopo un incidente, le voci di server web, PHP e database si lasciano comporre a fatica in una linea temporale.

Decidere consapevolmente conservazione e protezione dei dati

Per quanto tempo i log possano e debbano restare è un bilanciamento tra interesse alla sicurezza, minimizzazione dei dati e requisiti di legge o contrattuali. L'art. 32 GDPR richiede misure tecniche e organizzative adeguate al rischio, tra l'altro per garantire in modo duraturo riservatezza, integrità e disponibilità dei sistemi; la registrazione può contribuirvi. Al contempo i dati personali non possono essere conservati più a lungo del necessario.

Stabilisca quindi un termine per ogni tipo di log, metta per iscritto la motivazione e concordi entrambi con il suo responsabile della protezione dei dati. Per un'indagine in corso può essere necessario mettere al sicuro i log oltre il termine normale. Anche questo dovrebbe essere documentato. Questa pagina è un'informazione generale e non consulenza legale; per domande concrete aiutano responsabili della protezione dei dati e avvocati. Come analizzare i log dopo un attacco lo mostra Analizzare i log del server web dopo un attacco.

Come aiuta concretamente PHP SOS?

• Verifichiamo i suoi log esistenti alla ricerca di password, token e altri dati che lì non devono stare.
• Impostiamo PHP e applicazione in modo che gli errori siano registrati ma non visualizzati.
• Prepariamo una copia protetta dei log su un sistema separato.
• Con il monitoraggio della sicurezza analizziamo con continuità le voci rilevanti per la sicurezza e segnaliamo in modo comprensibile ciò che è anomalo.

Conclusione: i buoni log sono parchi nel contenuto e generosi nella protezione. Chi stabilisce oggi che cosa si registra e che cosa mai, nel caso grave ha tracce utilizzabili e nessuna fuga di dati aggiuntiva.

Domande frequenti

Fonti

• OWASP: Logging Cheat Sheet
• PHP-FIG: standard PSR
• Manuale PHP
• OWASP Top 10