Una traccia dello stack dovrebbe essere nel messaggio di errore presentato all'utente?

45

Ho un po 'di discussione sul mio posto di lavoro e sto cercando di capire chi ha ragione e qual è la cosa giusta da fare.

Contesto: un'applicazione Web intranet che i nostri clienti utilizzano per la contabilità e altre cose ERP.

Sono dell'opinione che un messaggio di errore presentato all'utente (quando le cose si arrestano in modo anomalo) dovrebbe includere quante più informazioni possibili, inclusa la traccia dello stack. Certo, deve iniziare con un bel "Si è verificato un errore, si prega di inviare le informazioni di seguito agli sviluppatori" in lettere grandi e amichevoli.

Il mio ragionamento è che uno screenshot dell'applicazione bloccata sarà spesso l'unica fonte di informazioni facilmente disponibile. Certo, puoi provare a contattare l'amministratore di sistema del cliente, provare a spiegare dove sono i tuoi file di registro, ecc., Ma probabilmente sarà lento e doloroso (parlare con i rappresentanti del client lo è per lo più).

Inoltre, avere informazioni immediate e complete è estremamente utile nello sviluppo, in cui non è necessario cercare i file di registro per trovare ciò di cui si ha bisogno in ogni eccezione. (Ma questo potrebbe essere risolto con un interruttore di configurazione.)

Sfortunatamente c'è stata una sorta di "audit di sicurezza" (non ho idea di come abbiano fatto senza le fonti ... ma qualunque cosa) e si sono lamentati dei messaggi di eccezione completi citandoli come una minaccia alla sicurezza. Naturalmente, i clienti (almeno uno di quelli che conosco) lo hanno preso in considerazione e ora richiedono che i messaggi vengano ripuliti.

Non riesco a vedere come un potenziale attaccante possa usare una traccia dello stack per capire qualcosa che non avrebbe potuto capire prima. Ci sono esempi, prove documentate di qualcuno che lo abbia mai fatto? Penso che dovremmo combattere questa idea folle, ma forse sono il pazzo qui, quindi ...

Chi ha ragione?

security error-handling

— Vilx-
fonte

25

Wow. Solo ... wow. " Unfortunately there has been some kind of "Security audit"" - Davvero? Che tipo di atteggiamento è quello? Gli audit di sicurezza sono a tuo vantaggio: migliorare i tuoi sistemi, trovare i problemi prima che i cattivi lo facciano. Dovresti davvero considerare di provare a lavorare con loro, non contro di loro. Inoltre, è possibile provare a ottenere ulteriori informazioni sul PoV di sicurezza su Sicurezza delle informazioni .

— AviD

7

E tra l'altro, un controllo di sicurezza non ha necessariamente bisogno dell'accesso al codice sorgente, probabilmente ha fatto un test di penetrazione black-box, simulando cosa farebbe un utente malintenzionato: prova ad attaccare l'applicazione come utente. Anche se concordo sul fatto che l'accesso al codice sorgente avrebbe potuto consentire una forma di audit molto più efficace. :-)

— AviD

1

@AviD - in verità, non so cosa abbiano analizzato, ma da alcuni rapporti ho visto che mi sembrava un test da scatola nera. Ad essere sincero, non voglio lavorare contro di loro. In effetti, mi sono piaciute le notizie quando le ho ascoltate. Ma questa loro particolare "vulnerabilità" mi sembra sciocca. In ogni decisione di sicurezza devi valutare la riduzione della minaccia rispetto alla riduzione dell'usabilità. In questo caso penso che riduca l'usabilità molto più di quanto migliora la sicurezza.

— Vilx-

1

Sono molto d'accordo sulla pesatura, ma non sono d'accordo sulla sua applicazione. Danneggia la sicurezza più di quanto pensi, e penso anche che la tua strada (dopo averlo fatto anche io, fino a quando non ho parlato con alcuni degli utenti .....) è peggiore per l'usabilità. Pensaci in termini orientati alle attività - come ha detto la risposta di @ Jon, il suo modo di fare il lavoro dell'utente molto meglio. L'utente non ha bisogno di preoccuparsi dello stack (a meno che i tuoi utenti non siano gli sviluppatori ...) Ma la mia esperienza è nella sicurezza e i rischi sono reali.

— AviD,

1

@AviD - Forse potresti indicarmi alcune risorse che spiegano come una traccia dello stack possa essere pericolosa? Sono pronto ad accettarlo, ma voglio qualcosa di più del principio generale di "mostrare solo ciò di cui hai bisogno".

— Vilx-

73

Tendo a creare un registro delle applicazioni, sia nel database che nel file, e registrare tutte queste informazioni. È quindi possibile fornire all'utente un numero di errore, che identifica a quale voce di registro è correlato l'errore, in modo da poterlo recuperare. Questo schema è utile anche perché puoi seguire gli errori anche se gli utenti non si preoccupano di risolverli con te, così puoi farti un'idea di dove siano i problemi.

Se il tuo sito è installato nell'ambiente di un client e non riesci a raggiungerlo, puoi richiedere al reparto IT in loco di inviarti un estratto in base all'errore n.

L'altra cosa che potresti considerare è avere i dettagli del sistema via e-mail degli errori su una casella di posta che vedi, quindi sai quando le cose vanno male.

Fondamentalmente avere un sistema che svuota le viscere quando qualcosa non va non ispira fiducia negli utenti non tecnici - tende a spaventarli nel pensare che qualcosa sia molto sbagliato (es. Quanto di un BSOD capisci e come ti senti quando uno arriva)?

Su stacktrace:

In .Net la traccia dello stack mostrerà la traccia completa direttamente negli assiemi di origine MS di base e rivelerà i dettagli su quali tecnologie stai usando e anche sulle possibili versioni. Ciò fornisce agli intrusi preziose informazioni su possibili punti deboli che potrebbero essere sfruttati.

— Jon Egerton
fonte

6

Mi piace la tua risposta perché presenta una "via di mezzo" - non mostrare, ma semplifica la ricerca delle eccezioni. Proverò a spingere per questo ora, spero che siano d'accordo. Grazie!

— Vilx-

2

Penso che questo sia praticamente l'approccio "maturo" standard. Inoltre, stacktrace fornisce moltissime informazioni, tuttavia devo ancora trovare una soluzione in grado di registrare automaticamente le informazioni sullo stato insieme allo stacktrace (senza che il codice cambi dappertutto). Sembra che scrivere il proprio debugger e collegarlo sia una strada possibile, ma tutt'altro che banale da implementare.

— Daniel B,

@DanielB: Nelle app Web è possibile ottenere alcune cose comuni (come userid, clientid ecc.) Dalla sessione / cache - poiché persistono "a livello globale", anche queste molte informazioni possono aiutare a riprodurre notevolmente gli errori. Più granulare di così è molto complicato come dici tu.

— Jon Egerton,

2

Alcuni utenti di applicazioni molto critiche richiedono soluzioni immediate a qualsiasi errore che impedisca il normale svolgimento dell'attività. Tutto il processo di comunicazione che coinvolge varie dicipline solo per consentire al risolutore di errori di acquisire la pila di errori può facilmente consumare 1 o più ore quando l'errore si verifica a tarda notte o nei fine settimana.

— Tulains Córdova,

1

@ user1598390: concordato, nel qual caso la copia dei dettagli dell'errore in una cassetta postale di supporto monitorata può accelerare la raccolta di informazioni, al punto che il personale di supporto sa che qualcosa è stato interrotto ancor prima che l'utente lo faccia.

— Jon Egerton,

29

Sì, ce ne sono molti.

Una traccia dello stack può rivelare

quale algoritmo di crittografia usi
quali sono alcuni percorsi esistenti sul server delle applicazioni
se si sta disinfettando correttamente l'input o meno
come i tuoi oggetti sono referenziati internamente
quale versione e marca del database si trova dietro il front-end

... La lista potrebbe continuare all'infinito. Fondamentalmente ogni decisione di progettazione in un'applicazione di grandi dimensioni potrebbe essere rilevante per la sicurezza e quasi tutte possono essere date via tramite nomi di metodi o moduli. Intendiamoci, ciò non significa che non abbia ancora senso visualizzare una traccia dello stack se l'ambiente a cui è sottoposto è sicuro (ad esempio una rete intranet anziché un sito Web con connessione a Internet), ma il costo in termini di sicurezza è decisamente diverso da zero .

— Kilian Foth
fonte

6

Sono d'accordo per la maggior parte, ma alcune di queste cose non dovrebbero importare. Ad esempio, quale algoritmo di crittografia che stai utilizzando non dovrebbe essere segreto per proteggere il tuo sistema.

— Oleksi,

3

Non dovrebbe importare, ma il mondo è imperfetto e spesso lo fa. Ecco perché la difesa in profondità (facendo molte cose contemporaneamente che dovrebbero essere sufficienti se fossero perfette) conta.

— Kilian Foth,

3

Francamente, se una traccia dello stack rivela qualcosa che potrebbe aiutare un attaccante, allora stai sbagliando !

— Mark Booth,

3

@MarkBooth statisticamente parlando, probabilmente stai sbagliando. No, grattalo - certezza statistica che stai sbagliando un po '. Vuoi davvero consentire agli aggressori di trovare i tuoi bug di sicurezza prima di farlo?

— AviD

1

@AviD - No, sono d'accordo, il motivo più convincente per non mostrare tracce di stack agli utenti è che non hanno idea di cosa fare con loro, e il tuo sistema di registrazione dovrebbe essere sicuro e in grado di catturare molto più stato di una schermata di una pagina web mai potrebbe.

— Mark Booth,

15

Il fatto è che non è il nostro compito principale rendere le cose più facili per noi stessi. Il nostro compito è semplificare le cose per l'utente finale. Per noi, una traccia dello stack sembra un'informazione estremamente utile per fornire uno sviluppatore. A un utente, sembra incomprensibile completo che non serve a nulla. Anche se dici loro diversamente, non lo interiorizzano. Se ritieni che sia difficile ottenere tali informazioni dagli amministratori di sistema, ottenerle dagli utenti finali è ancora peggio.

Per quanto riguarda la sicurezza, potresti avere un punto se fosse un'applicazione desktop. In tal caso, la stampa di una traccia dello stack non fornisce nulla che un attaccante non sappia già. Su un'app Web, tali informazioni non sono già disponibili per un utente malintenzionato. Stai davvero esponendo dettagli interni che renderanno un attacco molto più semplice.

Perché non ignorare entrambe le fonti di preoccupazione e ricevere automaticamente i rapporti sulle eccezioni? In questo modo non dovrai nemmeno preoccuparti che le persone non segnalino errori.

— Karl Bielefeldt
fonte

2

Gli utenti beneficiano di una rapida soluzione del proprio problema grazie alle informazioni fornite dalla traccia dello stack. Ma ho capito il tuo punto.

— Tulains Córdova,

11

Dai un'occhiata a questa domanda di IT Security SE . In breve, una traccia dello stack può fornire all'attaccante ulteriori informazioni su cui lavorare. Più informazioni ha l'attaccante, più è probabile che penetrino nel tuo sistema. Non baserei la mia sicurezza sul fatto che le tracce dello stack siano sempre nascoste, ma ciò non significa che dovresti fornire tali informazioni agli aggressori.

Puoi comunque ottenere la maggior parte dei vantaggi dalla corretta registrazione del back-end. È leggermente meno comodo, ma probabilmente non vale la pena rischiare la sicurezza del sistema e sconvolgere i clienti.

— Oleksi
fonte

8

Potresti considerare di non mostrare una traccia dello stack per i seguenti motivi.

Sicurezza

Mostrare una traccia dello stack rivela che le possibili superfici di attacco sarebbero hacker. Le intranet non sono immuni all'hacking. Rifletterebbe male su di te se la tua rete fosse stata hackerata a causa di un'applicazione di cui sei responsabile

L'esperienza utente

Per la migliore esperienza dell'utente, una traccia straccia è troppa informazione. Sì, le informazioni corrette su una condizione di errore devono essere registrate e prestate attenzione da un tecnico. Tuttavia, chiedere a un utente di fare ciò che è possibile automatizzare non sarà il massimo per l'utente.

La tua reputazione

Ogni volta che una traccia dello stack viene mostrata su un sito Web, sembra male. La maggior parte delle persone non ha idea di cosa sia e ciò li fa sentire come se il sito web non fosse amichevole con loro. Per coloro che sanno di cosa si tratta, potrebbe essere un'indicazione che l'applicazione non è stata ben pensata. Molte applicazioni scritte male mostrano troppo spesso tracce dello stack perché è l'impostazione predefinita in alcuni framework come ASP.Net.

— Tom Resing
fonte

6

Come sviluppatore di software, quando vedo una traccia dello stack sullo schermo, il mio immediato pensiero è "Ecco un bozo che non sa nulla sulla gestione degli errori, se ne frega di meno di loro, e probabilmente anche di meno sugli utenti". Altri ruotano attorno a "questo è un software scadente, non acceso non funziona, la sua gestione degli errori non funziona" e "WTF .... Non sto facendo questo lavoro per lui" Quello che il tuo utente vuole sapere è cosa deve fare per risolverlo. Come fa lo stack trace a farlo.

— mattnz,

6

Risposta breve: in un sito Internet o extranet, ha senso non mostrare lo stacktrace. In una intranet i vantaggi di mostrare lo stacktrace superano quelli di nasconderlo.

Risposta lunga:

Lo stesso è successo a me al lavoro. Pensavo che se un'app fallisce, dovrebbe fallire rumorosamente.

Ma poi mi hanno spiegato che un hacker potenziale potrebbe infliggere molte cose da uno stack.

Penso che non siano necessarie prove. È evidente che più un hacker conosce la tua piattaforma, meglio è per lui e meno un hacker conosce la tua piattaforma, meglio è per te .

Inoltre le aziende non sono ansiose di rivelare come un hacker ha fatto irruzione nei loro sistemi.

D'altra parte, è una rete intranet e penso che i vantaggi di sapere immediatamente cosa è andato storto senza dover cercare un file di registro sono di grande vantaggio e i rischi per la sicurezza di mostrare uno stack all'interno dei confini della tua azienda non sono alti quanto stanno dicendo.

— Tulains Córdova
fonte

1

quali sono alcuni dei "vantaggi di sapere immediatamente cosa è andato storto" e perché non possono essere recuperati da un file di registro? Sembrerebbe che con una rete Intranet sia possibile accedere a un file di registro anche più facilmente rispetto a un sito client.

— Wonko the Sane,

Nel mio scenario, ci sono applicazioni critiche che hanno la priorità "7/24". L'help desk di chiamata dell'utente, se il problema è un errore dell'applicazione o un'eccezione, l'help desk chiama il manutentore che forse è fuori sede. Con le informazioni sull'errore l'esperto può istruire una persona sul posto a una soluzione alternativa ... Spesso il tempo risparmiato è prezioso se l'app è critica per l'azienda. se l'esperto che, se non in sede, deve prima connettersi all'azienda, cercare nel registro, ecc., una funzione aziendale critica potrebbe essere in attesa inutilmente.

— Tulains Córdova,

3

@ user1598390 quindi crea un meccanismo di visualizzazione dei registri. Una semplice pagina Web, immettere l'ID incidente e l'helpdesk può visualizzare l'intero registro pertinente. Naturalmente limita l'accesso a questa funzione, e così via ...

— AviD,

Solo perché un'app si trova sull'intranet della tua azienda non significa che non vi siano utenti malintenzionati. Ci sono molti impiegati scontenti là fuori che potrebbero fare un uso improprio di un sistema interno a proprio vantaggio. Dato che questi dipendenti sanno molto della società e delle sue politiche, potrebbero effettivamente essere più pericolosi di un hacker interno. Passare attraverso i file di registro è un'attività piuttosto banale, soprattutto se si seguono le buone pratiche e si registrano anche gli errori in un file di registro degli errori specifico.

— cliff.meyers,

5

In qualsiasi prodotto consegnato, il numero previsto di questo tipo di errore dovrebbe essere zero. L'utilità di queste informazioni per il cliente è zero. In entrambi i casi, non c'è motivo di presentare una traccia dello stack. Se esiste un contesto utile, dovrebbe essere presentato in modo intuitivo, non come traccia dello stack.

D'altra parte, se il numero effettivo di occorrenze non è zero, hai disperatamente bisogno di queste informazioni e non dovresti fare affidamento sul cliente per inviarle. Il 99,99% delle volte no. È necessario installare un sistema di registrazione dei bug che invia automaticamente le informazioni, con solo un "ok" da parte del cliente.

— ddyer
fonte

Voterei questa risposta solo per la seguente riga: "L'utilità di queste informazioni per il cliente è zero". . Eventuali dettagli tecnici sugli interni di un prodotto devono essere nascosti a meno che non vi sia una buona ragione per non farlo per il semplice motivo di semplicità e usabilità per l'utente finale del prodotto.

— Kjartan,