Ogni volta che un'eccezione non gestita lo rende in qualche modo in produzione, è sicuro, valido, ecc. stampare una traccia di stack crittografata all'utente finale?

Pensa a perché vuoi farlo. È a mio parere, del tutto inutile.

Se l'eccezione si è verificata sul lato server, gestirla e registrarla lì. Non ha assolutamente senso visualizzare la traccia dello stack all'utente.

Se l'eccezione si è verificata sul lato client, in un'utile app Web di tipo client, app desktop, app mobile, ecc. non è assolutamente necessario crittografarlo. Qualsiasi utente sufficientemente determinato può decompilare o decodificare il codice lato client. Infatti, in che modo vorresti crittografare i dati? La crittografia implica una chiave di crittografia e questa chiave deve essere memorizzata da qualche parte.

Mi interrogo anche su cosa può fare un utente normale quando si visualizza la traccia dello stack. Se i dati di arresto anomalo sono informazioni importanti, implementare una sorta di funzionalità di reporting per la diagnostica.

Una traccia dello stack include raramente tutte le informazioni che riguardano problemi di sicurezza. Certo, potrebbe mostrare nomi di file sorgenti, numeri di linea e nomi di funzioni, ma non riuscivo a immaginare nessuna situazione in cui queste sarebbero informazioni preziose. Soprattutto considerando che questa informazione è memorizzata nell'eseguibile del programma che gira sulla macchina degli utenti. L'utente può estrarre manualmente le informazioni dall'applicazione quando lo desiderano.

Si potrebbe obiettare da un punto di vista User Experience se questa informazione è utile per utente. Potrebbe aiutarli a diagnosticare i problemi da soli. Potrebbero inserire la traccia dello stack in un motore di ricerca e potrebbero trovare qualcuno che ha avuto lo stesso problema e lo ha risolto in qualche modo. Un utente particolarmente esperto di tecnologia potrebbe persino utilizzare le informazioni per diagnosticare il problema da sé (quando lo stack-trace è in una funzione di un'API grafica, il problema potrebbe essere il mio driver della scheda grafica, ad esempio). Un utente meno esperto di tecnologia, tuttavia, potrebbe essere confuso da un messaggio di errore eccessivamente dettagliato. Ma come ho detto è tutto un problema di UX e non legato alla sicurezza.

Immagino che questa non sia un'applicazione web (per la quale è possibile registrare la traccia dello stack sul server) ma qualcosa come un'app desktop?

Prendiamo il caso seguente: eseguo il programma localmente e si blocca. Ricevo un messaggio che posso segnalare il problema allo sviluppatore. Voglio vedere cosa viene inviato. Poi vedo alcune informazioni crittografate. Mi chiedo di cosa si tratta e mi chiedo se i programmi inviino alcune informazioni private allo sviluppatore . Che dire della privacy? Come garantisci di non inviare informazioni personali?

Se hai a che fare con un'applicazione .Net, non ci sono molti motivi per crittografarla a meno che tu non stia usando un miracoloso obsolescente. .Net può essere banalmente decompilato e crittografare il dump dello stack dopo che le chiavi del regno sono già entrare per aprire non è poi così utile.

Se lo stanno eseguendo localmente, hanno la possibilità di alterare e analizzare il codice direttamente, incluso il collegamento di un debugger e semplicemente catturare lo stack da soli. Se è in esecuzione su un server, puoi registrarlo invece di visualizzarlo all'utente.

Un utente medio non sarà in grado di fare alcun uso di uno stack di chiamate e di qualsiasi utente che possa già conoscere strumenti come Reflector e come utilizzare i debugger per catturare le informazioni.

Nel caso in cui tu stia effettivamente usando l'offuscamento, allora sì, la crittografia dello stack trace potrebbe essere utile per rendere più probabile che entrambi i dati siano inalterati quando ti vengono inviati e anche proteggere le informazioni sullo stack delle chiamate da parte degli attaccanti che lo userebbe per cercare di capire l'offuscamento, anche se opportunamente offuscato, la maggior parte dello stack di chiamate sarà criptato per iniziare comunque poiché sostituire i nomi significativi con quelli inutili è una delle prime cose che un obfuscator fa.

Il motivo principale per cui ho potuto vedere per crittografare i rapporti sugli arresti anomali è ridurre la probabilità che qualcuno manchi il rapporto sugli arresti anomali e anche proteggere i dati degli utenti contenuti nel rapporto. Non vedo davvero una situazione in cui le informazioni che l'utente può raccogliere riguardo allo stack di chiamate è una preoccupazione importante, almeno non per un'applicazione .Net.

Gli altri utenti hanno già messo in dubbio la necessità di mostrare la traccia dello stack all'utente.

Penso che ci siano due ragioni per cui ci hai pensato: prima, sei l'utente e vuoi controllare gli errori che già conosci. O vuoi che l'utente dia la possibilità di inviare il rapporto crittografato.

C'è un modo molto migliore per gestire questo problema: consenti all'applicazione di segnalare automaticamente gli errori a un sistema di localizzazione degli errori ospitato come Exceptiontrap (Disclaimer: I'm the founder).

Questo ti offre diversi vantaggi:

• Sarai informato in tempo reale su tutti gli errori
• Sai con quale frequenza è successo un errore specifico e quando
• Il sistema raggruppa gli errori nei gruppi di errori
• Avrai la traccia dello stack e ulteriori informazioni sull'ambiente del server, i parametri di richiesta e così via
• Inoltre rimuove il problema di sicurezza di cui eri preoccupato

Come ho detto prima, sono il fondatore di Exceptiontrap , ma ci sono molti altri servizi disponibili.