Quanto si registra con 400 o 500 risposte HTTP?

La registrazione di solito non è un problema: mantieni i dati sensibili fuori dagli URL.

• fare URL di registro e metadati selezionati per richieste non riuscite.
  • non registra il corpo della richiesta per le richieste POST. Alcuni framework offrono una vista unificata su parametri application/x-www-form-urlencoded e parametri URL. Non registra questi parametri.
  • non registra in modo indiscriminato tutte le intestazioni delle richieste, in particolare l'autorizzazione o le intestazioni dei cookie.
• do registra una traccia dello stack sugli errori interni del server.
  • non include argomenti della funzione nello stack trace.
• fai aggiungi la registrazione a livello di applicazione al tuo codice per i valori selezionati.
  • non scrivi dati sensibili nel log.
  • non fai affidamento sul mascheramento o sulla redazione di valori sensibili nel tuo log. Per esempio. utilizzando una regex per filtrare i numeri delle carte di credito è fondamentalmente rotto.
  • non attiva la registrazione aggiuntiva a meno che tu non abbia attualmente bisogno di quelle informazioni.
• fai rivela la registrazione nella tua politica sulla privacy.
  • fai elenca i tipi di dati memorizzati.
  • fai specifica un periodo di conservazione.

Un errore di 400 client può indicare che:

• l'utente ha digitato in errore un URL (che non può essere corretto dall'utente),
• c'è un link interrotto o
• il tuo codice di front-end sta generando richieste non valide.

Nella maggior parte dei casi, la registrazione del codice di stato, dell'URL e del referrer è sufficiente per rilevare i problemi. Se è presente un problema ricorrente e sono necessarie ulteriori informazioni, abilitare la registrazione a livello di applicazione aggiuntiva. Ad esempio, l'utente che ha effettuato questa richiesta ha attualmente effettuato l'accesso? In alcuni casi, potrebbe essere necessario registrare i dati personali come gli ID utente. Dopo aver verificato una correzione, puoi disabilitare la registrazione aggiuntiva.

È bene pensare a come la registrazione può essere utilizzata in sicurezza. Il principio generale è di essere molto selettivo su ciò che immagazzini. Non scaricare una struttura dati complessa se può contenere dati sensibili. Ciò richiede anche che il flusso di controllo nell'applicazione sia abbastanza chiaro, in modo da sapere quali strutture di dati possono contenere dati sensibili. Nel caso particolare delle password, questo dovrebbe essere semplice: solo la funzionalità di registrazione / login / password-reset deve interagire con le password e queste possono essere riviste per verificarne la conformità.

Il fatto che alcune aziende non siano riuscite a proteggere le password non implica che abbiano utilizzato un approccio errato per la registrazione. Invece, potrebbe anche significare che avevano sviluppato un sistema sempre più complesso che non era più ovviamente sicuro. Le cose diventano rapidamente difficili quando le responsabilità per la gestione dei dati sensibili sono distribuite su più servizi o quando il codice che include la registrazione viene riutilizzato per gestire i dati riservati.

Il link Twitter che hai fornito spiega:

But because of a coding bug, Agrawal explained, "passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again."

Il numero di dipendenti con accesso a tali informazioni è limitato, se non avessero il numero di registrazioni necessario (livello di log), il problema potrebbe essere continuato da non scoprire per un po 'di tempo.

Per determinare il significato dei codici di errore vedi: Definizioni dei codici di stato , 4xx è " User Error 'e 5xx è' Server Error '- nel caso di 4xx l'utente non dovrebbe ripetere l'azione, nel caso di 5xx a volte l'utente può riprovare dopo passa un intervallo di tempo.

Mi piace un po 'troppo la registrazione invece che troppo poco, purché archivi (comprime) settimanalmente / giornalmente? e cancella dopo un certo periodo di tempo che non si esaurirà lo spazio.

Diverse situazioni richiedono un diverso livello di registrazione, raramente la registrazione è abbastanza dettagliata per regolare tutto correttamente e sarà necessario raggiungere il livello successivo.

Puoi utilizzare un account di prova per determinare se la tua password di prova è esposta e quindi grep l'origine per trovare la linea di registrazione incriminata e cancellare la password dalla linea di stampa.

Le persone dovrebbero sapere che tutto ciò che mettono online (crittografato o meno) è esposto a più persone, non è diverso dal gridare i tuoi segreti fuori dalla finestra del tuo veicolo mentre guidi lungo la strada - di solito l'informazione è di scarso valore o interesse per la maggior parte delle persone. Se non vuoi che nessuno lo sappia, non metterlo fuori.

Le persone che utilizzano il tuo server dovranno avere una quantità limitata di fiducia in te. Conoscete il loro IP, quando usano il vostro server e cosa fanno. Mantenere il loro hash password è un rispetto per la loro privacy che è possibile promettere, ma è più un problema di fiducia che prova (non li lasci visitare in momenti casuali per testare l'attrezzatura).

Registra ciò di cui hai bisogno per mantenere il tuo equipaggiamento e fornire un livello ragionevole di servizio. Tieni i dispositivi bloccati e non permettere alle persone (amici, dipendenti, ladri) di accedere a informazioni private. Quando il log è troppo vecchio per essere conservato, cancellalo. A volte si verificano errori casuali, nessun livello di registrazione aiuterà; altre volte verranno segnalati problemi e sarà necessario aumentare il livello del registro per determinare se l'errore si ripresenta.

Limita l'accesso ai registri a coloro che hanno bisogno di accesso per svolgere i loro compiti e far conoscere ai dipendenti la tua politica sulla privacy.