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

45

Tengo un poco de discusión en mi lugar de trabajo y estoy tratando de averiguar quién tiene la razón y qué es lo que hay que hacer.

Contexto: una aplicación web de intranet que nuestros clientes usan para contabilidad y otras cosas de ERP.

Soy de la opinión de que un mensaje de error presentado al usuario (cuando las cosas se bloquean) debe incluir tanta información como sea posible, incluido el seguimiento de la pila. Por supuesto, tiene que comenzar con un agradable "Se ha producido un error, envíe la siguiente información a los desarrolladores" en letras grandes y amigables.

Mi razonamiento es que una captura de pantalla de la aplicación bloqueada a menudo será la única fuente de información fácilmente disponible. Claro, puede intentar ponerse en contacto con los administradores de sistemas del cliente, intentar explicar dónde están sus archivos de registro, etc., pero eso probablemente será lento y doloroso (hablar con los representantes del cliente es mayormente).

Además, tener una información inmediata y completa es extremadamente útil en el desarrollo, donde no tiene que buscar los archivos de registro para encontrar lo que necesita en cada excepción. (Pero eso podría resolverse con un interruptor de configuración).

Desafortunadamente ha habido algún tipo de "auditoría de seguridad" (no tengo idea de cómo lo hicieron sin las fuentes ... pero lo que sea), y se quejaron de los mensajes de excepción completos que los citaban como una amenaza a la seguridad. Naturalmente, los clientes (al menos uno que conozco) lo han tomado al pie de la letra y ahora exigen que se limpien los mensajes.

No veo cómo un atacante potencial podría usar un seguimiento de pila para descubrir algo que no podría haber descubierto antes. ¿Hay algún ejemplo, alguna prueba documentada de que alguien haya hecho eso? Creo que deberíamos luchar contra esta idea tonta, pero tal vez yo soy el tonto aquí, así que ...

¿Quién tiene la razón?

security error-handling Vilx-
fuente
25
Guau. Simplemente guau. " Unfortunately there has been some kind of "Security audit"" - ¿En serio? ¿Qué tipo de actitud es esa? Las auditorías de seguridad son para su beneficio: para mejorar sus sistemas, para encontrar los problemas antes que los malos. Realmente deberías considerar tratar de trabajar con ellos, no en contra de ellos. Además, puede intentar obtener más información sobre el punto de vista de seguridad en Information Security .
AviD
77
Y, por cierto, una auditoría de seguridad no necesariamente necesita acceso al código fuente, probablemente hicieron una prueba de penetración de caja negra, simulando lo que haría un usuario malintencionado: intentar atacar la aplicación como usuario. Aunque estoy de acuerdo en que el acceso al código fuente podría haber permitido una forma de auditoría mucho más efectiva. :-)
AviD
1
@AviD: en verdad, no sé qué analizaron, pero de algunos informes vi que me pareció una prueba de recuadro negro. Para ser honesto, no quiero trabajar en contra de ellos. De hecho, me gustaron las noticias cuando las escuché. Pero esta "vulnerabilidad" particular de ellos me parece tonta. En cada decisión de seguridad, debe sopesar la reducción de amenazas contra la reducción de usabilidad. En este caso, creo que reduce la usabilidad mucho más de lo que mejora la seguridad.
Vilx-
1
Estoy muy de acuerdo con el pesaje, pero no estoy de acuerdo con su aplicación. Daña la seguridad más de lo que piensas, y también creo que tu forma de hacerlo (habiéndolo hecho yo también, hasta que hablé con algunos de los usuarios .....) es peor para la usabilidad. Piénselo en términos orientados a las tareas: como decía la respuesta de @ Jon, su forma de hacer el trabajo del usuario es mucho mejor. El usuario no necesita preocuparse por la pila (a menos que sus usuarios sean los desarrolladores ...) Pero, mi experiencia es en seguridad, y los riesgos son reales.
AviD
1
@AviD: ¿Tal vez pueda señalarme algunos recursos que expliquen cómo un seguimiento de la pila puede ser peligroso? Estoy listo para aceptar eso, pero quiero algo más que el principio general de "solo mostrar lo que necesita".
Vilx-

Respuestas:

73

Tiendo a construir un registro de aplicación, ya sea en DB o en archivo, y registrar toda esa información en 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 puede seguir los errores incluso si los usuarios no se molestan en plantearlos con usted, para que pueda 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 obtener el departamento de TI en el sitio para que le envíe un extracto basado en el error no.

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

Básicamente, tener un sistema que explota 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 (por ejemplo, qué tanto BSOD entiendes y cómo te sientes cuando aparece uno)

En stacktrace:

En .Net, el seguimiento de la pila mostrará el seguimiento completo directamente en los ensamblados centrales de MS y revelará 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 explotarse.

Jon Egerton
fuente
66
Me gusta su respuesta porque presenta un "camino intermedio": no se muestra, pero facilita la búsqueda de excepciones. Trataré de presionar por eso ahora, espero que estén de acuerdo. ¡Gracias!
Vilx-
2
Creo que este es más o menos el enfoque estándar "maduro". Además, stacktrace proporciona una gran cantidad de información, sin embargo, aún no he encontrado una solución que pueda registrar automáticamente la información de estado junto con el stacktrace (sin cambios de código en todas partes). Parece que escribir su propio depurador y adjuntarlo es una forma posible de hacerlo, pero lejos de ser trivial para implementar.
Daniel B
@DanielB: en las aplicaciones web es posible obtener algunas cosas comunes (como ID de usuario, ID de cliente, etc.) de la sesión / caché, ya que persiste "globalmente", incluso esta gran cantidad de información puede ayudar a reproducir errores en gran medida. Más granular que eso es muy complicado como dices.
Jon Egerton
2
Algunos usuarios de aplicaciones muy críticas exigen soluciones inmediatas a cualquier error que impida el curso normal de los negocios. Todo el proceso de comunicación que involucra varias disciplinas solo para que el solucionador de errores se apodere de la pila de errores puede consumir fácilmente 1 hora o más cuando el error ocurre tarde en la noche o los fines de semana.
Tulains Córdova
1
@ user1598390: De acuerdo, en cuyo caso la copia de los detalles del error en un buzón de soporte monitoreado puede acelerar la recopilación de información, hasta el punto de que el personal de soporte sabe que algo está roto incluso antes que el usuario.
Jon Egerton el
29

Sí, hay muchos.

Un rastro de pila puede revelar

  • qué algoritmo de encriptación usas
  • cuáles son algunas rutas existentes en su servidor de aplicaciones
  • si está desinfectando correctamente la entrada o no
  • cómo se hace referencia internamente a sus objetos
  • qué versión y marca de base de datos está detrás de su front-end

... La lista sigue y sigue. Básicamente, cada decisión de diseño en una aplicación grande puede ser relevante para la seguridad, y casi todas se pueden regalar a través de métodos o nombres de módulos. Eso sí, 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 con conexión a Internet), pero el costo en seguridad definitivamente no es cero .

Kilian Foth
fuente
66
Estoy de acuerdo en su mayor parte, pero algunas de estas cosas no deberían importar. Por ejemplo, qué algoritmo de cifrado está utilizando no debería ser secreto para proteger su sistema.
Oleksi
3
No debería importar, pero el mundo es imperfecto, y a menudo lo hace. Es por eso que la defensa en profundidad (hacer muchas cosas simultáneamente que deberían ser suficientes si fueran perfectas) es importante.
Kilian Foth
3
Francamente, si un seguimiento de la pila revela algo que podría ayudar a un atacante, ¡entonces lo estás haciendo mal !
Mark Booth el
3
@MarkBooth estadísticamente hablando, probablemente lo estás haciendo mal. No, tacha eso: certeza estadística de que te estás equivocando. ¿Realmente quieres dejar que los atacantes encuentren tus errores de seguridad antes que tú?
AviD
1
@AviD: No, estoy de acuerdo, la razón más convincente para no mostrar los rastros de la pila a los usuarios es que no tienen idea de qué hacer con ellos, y su sistema de registro debe ser seguro y capaz de capturar mucho más estado que una captura de pantalla de una página web podría alguna vez.
Mark Booth
15

La cuestión es que no es nuestro trabajo principal facilitarnos las cosas. Nuestro trabajo es facilitar las cosas al usuario final. Para nosotros, un seguimiento de pila parece una información extremadamente útil para proporcionar un desarrollador. Para un usuario, parece un galimatías completo que no sirve de 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, es aún peor obtenerla de los usuarios finales.

En lo que respecta a la seguridad, es posible que tenga un punto si se trata de una aplicación de escritorio. En ese caso, imprimir un seguimiento de pila no proporciona nada que un atacante ya no sepa. En una aplicación web, esa información no está disponible para un atacante. De hecho, está exponiendo detalles internos que harán que un ataque sea mucho más fácil.

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

Karl Bielefeldt
fuente
2
Los usuarios se benefician de una solución rápida de su problema gracias a la información proporcionada por el seguimiento de la pila. Pero entiendo tu punto.
Tulains Córdova
11

Eche un vistazo a esta pregunta de IT Security SE . En resumen, un seguimiento de la pila puede proporcionar al atacante más información para trabajar. Cuanta más información tenga el atacante, es más probable que penetre en su sistema. No basaría mi seguridad en el hecho de que los rastros de la pila siempre están ocultos, pero eso tampoco significa que deba dar esa información a los atacantes.

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

Oleksi
fuente
8

Puede considerar no mostrar un seguimiento de la pila por los siguientes motivos.

Seguridad

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

Experiencia de usuario

Para la mejor experiencia del usuario, una traza de seguimiento es demasiada información. Sí, la información adecuada sobre una condición de error debe registrarse y recibir atención de un ingeniero. Sin embargo, pedirle a un usuario que haga lo que puede automatizar no será lo mejor para el usuario.

Tu 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 sí saben lo que es, puede ser una indicación de que la aplicación no fue bien pensada. Muchas aplicaciones mal escritas muestran trazas de pila con demasiada frecuencia porque es el valor predeterminado en algunos marcos como ASP.Net.

Tom Resing
fuente
66
Como desarrollador de software, cuando veo un rastro de la pila en la pantalla, mi opinión inmediata es: "Aquí hay un bozo que no sabe nada sobre el manejo de errores, se preocupa menos por ellos y, probablemente, aún menos sobre los usuarios". Otros giran en torno a "este es un software de mierda, no funciona, no funciona, su manejo de errores no funciona" y "WTF ... No estoy haciendo este trabajo para él" Lo que tu usuario quiere saber es qué él necesita hacer para arreglarlo. ¿Cómo hace el seguimiento de la pila?
mattnz
6

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

Respuesta larga:

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

Pero luego me explicaron que un pirata informático potencial podría inferir muchas cosas de un stacktrace.

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

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

Por otro lado, es una intranet , y creo que las ventajas de saber de inmediato qué salió mal sin tener que buscar un archivo de registro son una gran ventaja y los riesgos de seguridad de mostrar un seguimiento de pila dentro de los límites de su empresa no son tan altos como ellos están diciendo.

Tulains Córdova
fuente
1
¿Cuáles son algunas de las "ventajas de saber de inmediato qué salió mal" y por qué no se pueden recuperar de un archivo de registro? Parecería que con una Intranet, podría acceder a un archivo de registro incluso más fácilmente que desde un sitio cliente.
Wonko the Sane
En mi escenario, hay aplicaciones críticas que tienen prioridad "7/24". El usuario llama a la mesa de ayuda, si el problema es un error de la aplicación o una excepción, la mesa de ayuda llama al encargado que tal vez esté fuera de las instalaciones. Con la información de error, el experto puede instruir a una persona en el sitio a una solución ... Muchas veces el tiempo ahorrado es valioso si la aplicación es crítica para el negocio. Si el experto que fuera de las premisas tiene que conectarse primero con la empresa, buscar en el registro, etc., una función comercial crítica podría estar esperando innecesariamente.
Tulains Córdova
3
@ user1598390, así que cree un mecanismo de visualización de registros. Una página web simple, ingrese la identificación del incidente, y el servicio de asistencia puede ver todo el registro relevante. Por supuesto, limite el acceso a esta función, y así sucesivamente ...
AviD
El hecho de que una aplicación esté en la intranet de su empresa no significa que no haya usuarios maliciosos en ella. Hay muchos empleados descontentos por ahí que muy bien podrían usar mal un sistema interno para su propio beneficio. Dado que estos empleados saben mucho sobre la compañía y sus políticas, en realidad podrían ser más peligrosos que un hacker interno. Revisar los archivos de registro es una tarea bastante trivial, especialmente si sigue una buena práctica y también registra errores en un archivo de registro de errores específico.
cliff.meyers
5

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 un seguimiento de la pila. Si hay algún contexto útil, debe presentarse de manera amigable para el cliente, no como un seguimiento de la pila.

Por otro lado, si el número real de ocurrencias no es cero, necesita desesperadamente esta información y no debe confiar en que el cliente se la envíe. 99.99% de las veces no lo harán. Debe instalar un sistema de respuesta de errores que envíe la información automáticamente, con solo un "ok" del cliente.

ddyer
fuente
Votaría esta respuesta solo para la siguiente línea: "La utilidad de esta información para el cliente es cero". . Cualquier detalle técnico sobre las partes internas de un producto debe estar oculto a menos que haya una buena razón para no hacerlo por la simple razón de la simplicidad y facilidad de uso para el usuario final del producto.
Kjartan