¿Debería haber un seguimiento de pila en el mensaje de error presentado al usuario?

Tiendo a crear un registro de aplicación, ya sea en DB o en archivo, y registrar toda esa información para eso. Luego, puede darle al usuario un número de error, que identifica con qué elemento de registro está relacionado el error, para que pueda recuperarlo. Este patrón también es útil, ya que puedes seguir los errores incluso si los usuarios no se molestan en subirlos contigo, para que puedas tener una mejor idea de dónde están los problemas.

Si su sitio está instalado en el entorno de un cliente y no puede acceder a él, puede hacer que el departamento de TI en el sitio le envíe un extracto basado en el error no.

La otra cosa que podría considerar es tener los detalles de los errores del correo electrónico del sistema en un buzón que tenga a la vista, para que sepa cuándo las cosas van mal.

Fundamentalmente, tener un sistema que se desvele cuando algo no está bien no inspira confianza en los usuarios no técnicos, tiende a asustarlos para que piensen que algo está muy mal (p. ej., ¿cuánto de un BSOD entiende? ¿Y cómo te sientes cuando surge uno?

En stacktrace:

En .Net, la traza de la pila mostrará la traza completa directamente en los ensamblajes de origen de MS del núcleo, y revelará los detalles sobre las tecnologías que está utilizando y las posibles versiones también. Esto proporciona a los intrusos información valiosa sobre posibles debilidades que podrían ser explotadas.

Sí, hay muchos.

Una traza de pila puede revelar

• qué algoritmo de cifrado utilizas
• cuáles son algunas de las rutas existentes en su servidor de aplicaciones
• si estás saneando correctamente la entrada o no
• cómo se hace referencia interna a tus objetos
• qué versión y marca de base de datos están detrás de tu interfaz

... la lista sigue y sigue. Básicamente, todas las decisiones de diseño en una aplicación grande podrían ser relevantes para la seguridad, y casi todas pueden darse a través de nombres de métodos o módulos. Tenga en cuenta que eso no significa que todavía no tenga sentido mostrar un seguimiento de la pila si el entorno al que se envía es seguro (por ejemplo, una intranet en lugar de un sitio web orientado a Internet), pero el costo en seguridad definitivamente no es cero .

La cuestión es que no es nuestro trabajo principal hacer las cosas más fáciles para nosotros mismos. Es nuestro trabajo hacer las cosas más fáciles para el usuario final. Para nosotros, un seguimiento de pila parece una pieza de información extremadamente útil para proporcionar un desarrollador. Para un usuario, parece una completa confusión que no sirve para nada. Incluso si les dices lo contrario, no lo internalizan. Si cree que es difícil obtener esa información de los administradores del sistema, obtenerla de los usuarios finales es aún peor.

En cuanto a la seguridad, puede tener un punto si se tratara de una aplicación de escritorio. En ese caso, imprimir un seguimiento de la pila no proporciona nada que un atacante no sepa. En una aplicación web, esa información no está disponible para un atacante. De hecho, estás exponiendo los detalles internos que harán que un ataque sea lot más fácil.

¿Por qué no omitir ambas fuentes de preocupación y recibir informes de excepciones automáticamente? De esa manera, ni siquiera tiene que preocuparse por que las personas no informen errores.

Eche un vistazo a Esta pregunta de IT Security SE . En resumen, una traza de pila puede dar al atacante más información para trabajar. Cuanta más información tenga el atacante, mayor será la probabilidad de que penetren en su sistema. No basaría mi seguridad en el hecho de que los rastros de pila siempre están ocultos, pero eso tampoco significa que debas dar esa información a los atacantes.

De todos modos, puede obtener la mayoría de los beneficios del registro de back-end adecuado. Es un poco menos conveniente, pero probablemente no vale la pena arriesgar la seguridad de su sistema y molestar a sus clientes.

Podría considerar no mostrar un seguimiento de pila por los siguientes motivos.

Seguridad

Mostrar un seguimiento de pila revela posibles superficies de ataque para los hackers. Las intranets no son inmunes a la piratería. Se reflejaría mal en usted si su red fue hackeada debido a una aplicación de la que es responsable

Experiencia de usuario

Para la mejor experiencia del usuario, un rastreo de strack es demasiada información. Sí, la información correcta sobre una condición de error debe ser registrada y prestada a un ingeniero. Sin embargo, pedirle a un usuario que haga lo que puede automatizar no será lo mejor para el usuario.

Su reputación

Cada vez que se muestra un seguimiento de pila en un sitio web, se ve mal. La mayoría de las personas no tienen idea de qué es y eso les hace sentir que el sitio web no es amigable para ellos. Para aquellos que saben qué es, puede ser una indicación de que la aplicación no fue bien pensada. Muchas aplicaciones mal escritas muestran los rastreos de la pila con demasiada frecuencia porque es la opción predeterminada en algunos marcos como ASP.Net.

Respuesta corta: en una extranet o en un sitio de Internet, tiene sentido no mostrar el seguimiento de pila. En una intranet, los beneficios de mostrar el stacktrace superan a los de ocultarlo.

Respuesta larga:

Lo mismo me pasó a mí en el trabajo. Solía pensar que si una aplicación falla, debería fallar ruidosamente.

Pero luego me explicaron que un potencial pirata informático podía infiltrar muchas cosas desde un seguimiento de pila.

Creo que no hay necesidad de pruebas. Es evidente que cuanto más sepa un pirata informático sobre su plataforma, mejor será para él y que cuanto menos sepa un pirata informático sobre su plataforma, mejor será para usted .

Además, las empresas no están dispuestas a revelar cómo un hacker irrumpió en sus sistemas.

Por otra parte, es una intranet , y creo que las ventajas de saber de inmediato lo que salió mal sin tener que buscar un archivo de registro es una gran ventaja y Los riesgos de seguridad de mostrar un stacktrace dentro de los límites de su empresa no son tan altos como dicen.

En cualquier producto entregado, el número esperado de este tipo de error debe ser cero. La utilidad de esta información para el cliente es cero. En ambos casos, no hay razón para presentar una traza de pila. Si hay algún contexto útil, debe presentarse de forma amigable para el cliente, no como un seguimiento de pila.

Por otra parte, si el número real de incidencias no es cero, necesita desesperadamente esta información y no debe confiar en que el cliente se la envíe. El 99,99% del tiempo no lo harán. Debe instalar un sistema de notificación de errores que envíe la información de manera automática, con solo un "ok" del cliente.