Dovrebbe esserci una traccia di stack nel messaggio di errore presentato all'utente?

Tendo a creare un registro di applicazione, in DB o in file, e registro tutte queste informazioni a tale scopo. È quindi possibile fornire all'utente un numero di errore, che identifica la voce del registro a cui è correlato l'errore, in modo da poterlo recuperare. Questo modello è anche utile in quanto puoi seguire gli errori anche se gli utenti non si preoccupano di sollevarli con te, così puoi avere un'idea migliore di dove sono i problemi.

Se il tuo sito è installato nell'ambiente di un cliente e non puoi raggiungerlo, puoi richiedere all'IT IT in loco di inviarti un estratto basato sul numero errore

L'altra cosa che potresti considerare è avere i dettagli e-mail di sistema degli errori in una casella di posta che hai visto, così sai quando le cose stanno andando male.

Fondamentalmente avere un sistema che si rovescia quando qualcosa non va bene 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 viene fuori?

On stacktrace:

In .Net, la traccia dello stack mostrerà la traccia completa direttamente negli assembly MS originari, e rivelerà i dettagli su quali tecnologie si stanno utilizzando e le possibili versioni. Ciò fornisce agli intrusi informazioni preziose su possibili punti deboli che potrebbero essere sfruttati.

Sì, ce ne sono molti.

Una traccia dello stack può rivelare

• quale algoritmo di crittografia utilizzi
• quali sono alcuni percorsi esistenti sul server delle applicazioni
• se si sta disinfettando o meno l'input
• il modo in cui i tuoi oggetti sono referenziati internamente
• quale versione e marca del database si trovano dietro il front-end

... l'elenco potrebbe continuare all'infinito. Fondamentalmente ogni decisione progettuale in una grande applicazione potrebbe essere rilevante per la sicurezza, e quasi tutte possono essere date via attraverso i nomi dei metodi o dei moduli. Intendiamoci, ciò non significa che non abbia ancora senso visualizzare una traccia di stack se l'ambiente a cui è sottoposto è sicuro (ad esempio una intranet piuttosto che un sito internet), ma il costo in sicurezza è sicuramente non pari a zero .

Il fatto è che non è il nostro compito principale rendere le cose più facili su noi stessi. Il nostro compito è semplificare le cose all'utente finale. Per noi, una traccia di stack sembra una informazione estremamente utile per fornire uno sviluppatore. Per un utente, sembra completo senza senso che non è di alcuna utilità. Anche se gli dici diversamente, non lo interiorizzano. Se pensi che sia difficile ottenere queste informazioni dagli amministratori di sistema, ottenerle dagli utenti finali è anche peggio.

Per quanto riguarda la sicurezza, potresti avere un punto se si tratta di un'applicazione desktop. In tal caso, la stampa di una traccia di stack non fornisce nulla che un utente malintenzionato non conosca già. Su un'app Web, tali informazioni non sono già disponibili per un utente malintenzionato. In effetti stai esponendo dettagli interni che renderanno un attacco molto più facile.

Perché non ignorare entrambe le fonti di preoccupazione e ottenere automaticamente rapporti di eccezione inviati a voi? In questo modo non devi neanche preoccuparti di persone che non riportano errori.

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

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

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

Sicurezza

Mostrare una traccia di stack rivela possibili superfici di attacco per gli hacker. Le intranet non sono immuni dall'hacking. Ti rifletterebbe male se la tua rete fosse compromessa a causa di un'applicazione di cui sei responsabile

Esperienza utente

Per la migliore esperienza dell'utente, una traccia strack è troppe informazioni. Sì, le informazioni corrette su una condizione di errore devono essere registrate e fornite da un tecnico. Tuttavia, chiedere a un utente di fare ciò che puoi automatizzare non sarà il migliore per l'utente.

La tua reputazione

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

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

Risposta lunga:

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

Ma poi mi hanno spiegato che un hacker potenziale potrebbe infere molte cose da uno stacktrace.

Penso che non ci sia bisogno di prove. È evidente che più un hacker conosce la tua piattaforma, meglio è per lui e che meno un pirata conosce la tua piattaforma meglio è per te .

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

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

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 c'è un contesto utile, dovrebbe essere presentato in modo amichevole per il cliente, non come traccia dello stack.

D'altra parte, se il numero effettivo di occorrenze non è pari a zero, hai bisogno di queste informazioni e non dovresti affidarti al cliente per inviarlo a te. 99,99% del tempo in cui non lo faranno. Dovresti installare un sistema di segnalazione errori che invia automaticamente le informazioni, con solo un "ok" dal cliente.