¿Cada vez que una excepción no manejada se convierte en producción, es seguro, viable, etc. para imprimir un seguimiento de pila cifrado para el usuario final?

Piensa en por qué quieres hacer esto. En mi opinión, es totalmente inútil.

Si la excepción ocurrió en el lado del servidor, manéjelo y regístrese allí. No tiene ningún sentido mostrar el seguimiento de la pila al usuario.

Si la excepción se produjo en el lado del cliente, en una aplicación web de estilo cliente grueso, aplicación de escritorio, aplicación móvil, etc., no tiene ningún sentido cifrarla. Cualquier usuario suficientemente determinado puede descompilar o aplicar ingeniería inversa al código del lado del cliente. De hecho, ¿cómo cifraría los datos? El cifrado implica una clave de cifrado, y esta clave debe almacenarse en algún lugar.

También cuestiono qué puede hacer un usuario normal cuando se muestra el seguimiento de la pila. Si los datos de fallos son información importante, implemente algún tipo de funcionalidad de informes para los diagnósticos.

Un seguimiento de pila rara vez incluye información que sea de seguridad. Claro, puede mostrar nombres de archivos de origen, números de línea y nombres de funciones, pero no puedo imaginar ninguna situación en la que estos sean información valiosa. Especialmente teniendo en cuenta que esta información se almacena en el ejecutable del programa que se ejecuta en la máquina del usuario. El usuario podría extraer esa información de la aplicación manualmente cuando lo desee.

Uno podría argumentar desde el punto de vista Experiencia del usuario si esta información es útil para la usuario. Podría ayudarles a auto-diagnosticar problemas. Podían ingresar el rastreo de la pila en un motor de búsqueda y encontrar a alguien que tuviera el mismo problema y lo resolviera de alguna manera. Un usuario especialmente experto en tecnología podría incluso utilizar la información para diagnosticar el problema por sí mismo (cuando el seguimiento de la pila se encuentra en una función de una API gráfica, el problema podría ser el controlador de mi tarjeta gráfica, por ejemplo). Sin embargo, un mensaje de error excesivamente detallado podría confundir a un usuario menos experto en tecnología. Pero como dije, eso es todo un problema de UX y no está relacionado con la seguridad.

Supongo que esto no es una aplicación web (para la que podría registrar el seguimiento de la pila en el servidor) sino algo así como una aplicación de escritorio

Toma el siguiente caso: ejecuto el programa localmente, y se bloquea. Recibo un mensaje de que puedo informar el problema al desarrollador. Quiero ver lo que se envía. Entonces veo algo de información encriptada. Me pregunto qué es, y me pregunto si los programas envían alguna información privada al desarrollador . Entonces, ¿qué pasa con la privacidad? ¿Cómo garantiza que no envía información personal?

Si estás tratando con una aplicación .Net, no hay muchas razones para cifrarla a menos que estés usando un buen ofuscador. .Net puede ser trivialmente descompilado y cifrar el volcado de pila una vez que las claves del reino ya están salir a abrir no es tan útil.

Si lo ejecutan localmente, entonces tienen la capacidad de alterar y analizar el código directamente, lo que incluye adjuntar un depurador y simplemente capturar la pila ellos mismos. Si se está ejecutando en un servidor, puede registrarlo en lugar de mostrarlo al usuario.

Un usuario promedio no podrá hacer uso de una pila de llamadas y cualquier usuario que ya pueda conocer herramientas como Reflector y cómo usar los depuradores para capturar la información.

En el caso de que realmente esté utilizando ofuscación, entonces sí, cifrar el seguimiento de la pila podría ser útil para aumentar la probabilidad de que no se alteren los datos cuando se le envíen y también proteger la información sobre la pila de llamadas sería atacante eso lo usaría para tratar de descubrir la ofuscación, aunque se ofuscó correctamente, la mayoría de la pila de llamadas va a estar revuelta para comenzar de todos modos ya que reemplazar nombres significativos con nombres inútiles es una de las primeras cosas que hace un ofuscador.

La razón principal que podría ver para cifrar sus informes de fallos es reducir la posibilidad de que alguien manipule el informe de fallos y también proteger los datos de los usuarios que se encuentran en el informe. Realmente no veo una situación en la que la información que el usuario pueda obtener sobre la pila de llamadas sea una preocupación importante, al menos no para una aplicación .Net.

Los otros usuarios ya cuestionaron la necesidad de mostrar el seguimiento de la pila al usuario.

Creo que hay dos razones por las que pensaste en eso: primero, eres el usuario y quieres inspeccionar los errores que ya conoces. O desea que el usuario otorgue la posibilidad de enviar el informe cifrado.

Hay una manera mucho mejor de lidiar con esto: deje que la aplicación informe automáticamente los errores a un sistema de seguimiento de errores alojado como Exceptiontrap (Descargo de responsabilidad: Soy el fundador).

Esto le proporciona varias ventajas:

• Se le informará en tiempo real sobre todos los errores
• Usted sabe con qué frecuencia ocurre un error específico y cuándo
• El sistema agrupa los errores en grupos de errores
• Tendrá el seguimiento de la pila y la información adicional sobre el entorno del servidor, los parámetros de solicitud, etc.
• Además, elimina la preocupación de seguridad que temía

Como dije antes, soy el fundador de Exceptiontrap , pero hay otros servicios disponibles.