Il back-end di un'applicazione è in grado di registrare potenzialmente dati sensibili dei clienti in modalità di debug?

Question

Il back-end di un'applicazione è in grado di registrare potenzialmente dati sensibili dei clienti in modalità di debug?

#1 da (2 voti)
#2 da (1 voti)

5

Poiché sto lavorando a un sito Web che chiede ai clienti di immettere dati quali nome, indirizzo, numero di telefono, ovviamente dati dei clienti che devono essere protetti.

Faccio del mio meglio per non registrare tali dati (sebbene disponga di due livelli di log: normale e sicuro, e utilizzerei l'area di registro sicura per tali), mi chiedo se un'applicazione non dovrebbe ancora registrare i dati dei clienti quando si trova in modalità debug o traccia. Tutti questi log avvengono sul lato server. Il client non ha alcun controllo su di esso.

Nella mia attuale implementazione, la modalità di rilascio normale non lo farebbe nei livelli di registro INFO, WARNING o ERROR, ma i livelli DEBUG / TRACE potrebbero perdere parte di tali informazioni nei registri. Questo comportamento è previsto nella maggior parte dei server web? O dovremmo cercare di limitare tali perdite anche in modalità DEBUG, TRACE? (nota che la nostra applicazione C ++ è compilata in modalità di rilascio, il "DEBUG" in questo caso fa riferimento al livello di log e non al fatto che nel software sia ancora presente del codice di debug.)

Si noti che l'applicazione può registrare i dati su un altro computer o anche su un sistema di terze parti, quindi l'accesso di sicurezza ai registri è indipendente dall'accesso all'applicazione del server del sito Web o al database in cui, ovviamente, i dati sono sicuri. Tuttavia, posso immaginare che alcune persone abbiano requisiti di sicurezza inferiori sui loro computer di registro rispetto ai computer con il database ...

logging websites webserver web-application data-leakage

posta Alexis Wilke 11.04.2016 - 23:58

fonte

2 risposte

1

Ho lavorato come tester di penetrazione dalla fine degli anni '90 e ho visto molte applicazioni. Non è raro che una volta ogni tanto un'applicazione registri i dati di identificazione dell'utente. La maggior parte degli sviluppatori dichiara che le persone hanno accesso ai log come affidabili e quindi non limitano la registrazione.

Se questo potrebbe essere un problema dipende dal business case e dal livello di sicurezza desiderato. Nel mio parere professionale, le password di registrazione non sono mai consentite. È possibile registrare il primo carattere e la lunghezza se necessario. Ma niente di più. Altrimenti si compromette il desiderio di crittografare le password in movimento e durante il riposo.

In ambienti ad alta sicurezza questo potrebbe essere applicato anche ad altri dati come nomi utente, nomi, indirizzi, numeri di conto bancario, ecc.

risposta data 04.06.2016 - 02:45

fonte

Leggi altre domande sui tag logging websites webserver web-application data-leakage

Test di penetrazione basato sul Web che utilizza MD5 per la password Posso riparare una carta di credito cut-through?

score 2 · Accepted Answer

Questa è una bella domanda! Sono anche uno sviluppatore di un prodotto c ++ che gestisce dati ad alta sensibilità e affrontiamo questo dilemma quasi ogni giorno.

Quando un sistema di produzione inizia a lanciare allarmi (soprattutto quelli relativi alle prestazioni o alla configurazione, si applicano anche problemi software / bug non corretti) spesso è necessario attivare temporaneamente il debug a livello di traccia stack per diagnosticare il problema. Questi registri contengono inevitabilmente informazioni sensibili: gli indirizzi IP o gli utenti coinvolti nella transazione, a volte pezzi di dati, è il nome. Spesso i nostri clienti non si sentono a proprio agio nel darci questi registri per ovvi motivi. È dura.

Gli amministratori che eseguono effettivamente il server sapranno quale livello di sensibilità sono i loro dati e quali politiche di sicurezza governative o settoriali devono seguire quando lo gestiscono (ad esempio: i dati governativi, finanziari e sanitari hanno regole speciali). È giusto che il tuo software abbia la capacità di produrre registri sensibili, ma gli amministratori devono avere il pieno controllo di come, quando e dove vengono prodotti e archiviati.

Alcune cose che puoi fare:

Assicurati di stare molto attento a classificare correttamente tutti i messaggi di errore contenenti (anche potenzialmente) informazioni sensibili nel livello di registro corretto: INFO, AVVERTENZA, ERRORE, DEBUG, TRACCIA, ecc.
Sii esplicito nella tua documentazione sui tipi di informazioni sensibili incluse in ciascun livello di registro. Più sono i dettagli, meglio è, quindi gli amministratori attenti alla sicurezza possono svolgere correttamente il proprio lavoro.
Assicurati che il livello di registro DEBUG / TRACE sia disattivato nella configurazione predefinita del software e che l'amministratore debba eseguire una serie di avvisi per attivarla (ovvero non è possibile farlo per errore).
È possibile inviare registri di livello DEBUG / TRACE a un flusso di log separato (hai menzionato un log "sicuro" separato) che per impostazione predefinita è lo storage locale, rendendo più difficile spedirlo "accidentalmente" all'esterno della zona protetta o miscelarlo con i log standard
Invia il tuo prodotto con uno strumento di redazione che sappia come mascherare tutti i dati grezzi, i nomi utente, gli indirizzi IP, ecc. dai tuoi registri DEBUG / TRACE con segnaposti unici (ciascun nome utente / IP univoco viene mascherato da un unico A, B,. ., AA, ecc.). Spesso l'effettivo nome utente / IP / dati è irrilevante, ma la chiave per diagnosticare il problema è che l'errore si verifica solo con dati di tipo X, o che l'indirizzo IP A (e solo A) invia sempre sempre le sue richieste tre volte, o qualsiasi altra cosa . In questo modo, un amministratore può essere sicuro che non rilevi perdite di dati sensibili se mai è necessario spostare questi registri fuori dalla zona protetta (ad esempio, inviandoli a te per il debug).

In conclusione: Penso sia giusto che il tuo software abbia la possibilità di registrare informazioni sensibili a scopo di debug e ti ringrazierai più tardi quando dovrai eseguire il debug di un sistema di produzione malfunzionante! Ma rendi il più difficile possibile attivare "per sbaglio". Affidati agli amministratori per conoscere i loro requisiti di sicurezza e facilita il loro lavoro.