¿Es seguro mostrar un error de consulta de MySQL en la página web si algo salió mal?

Los usuarios finales nunca deben ver los detalles sangrientos de su entorno.

En cambio, es más profesional mostrar una página genérica de 'Lo siento, algo salió mal'. Al menos los visitantes pueden ver que tiene un mecanismo real de manejo de errores presente en su sitio web.

Sin embargo, esos errores deben escribirse en el registro de errores de mysql y también deben activar una notificación por correo electrónico o de otra manera al equipo de TI. Esos errores no deberían ocurrir, por lo que puede ser una señal de que su sitio está fallando o posiblemente esté bajo ataque.

No, definitivamente no es seguro porque crea vectores de ataque de inyección SQL adicionales que no están presentes de otra manera. Ejemplo: si tiene un flujo de inyección de SQL en una inserción, entonces este es un tipo de inyección "ciega" porque la inserción no informa de ninguna fila de resultados a la persona que llama. Pero si trae un mensaje de error de inserción potencial al cliente, entonces lo hace vulnerable a la llamada inyección "XPath" (consulte este documento para más detalles). La esencia es que inyectas una función xml que se supone que calcula una variable de tipo de datos xml. Uno de los argumentos de la función es una variable xpath que se puede calcular de nuevo mediante declaraciones selectas y concatenación de cadenas. En lugar de proporcionar una xpath válida, debe hacer una selección (por ejemplo, "seleccione password_hash de los usuarios donde id = 'admin'"). Por lo tanto, el DB ejecutará un INSERT que está intencionalmente incorrecto a través de su inyección. El resultado será un mensaje de error como

'bb9af55cd325deaa89bb7b4e36085b4d' is not a valid xpath

Si muestra mensajes de error como estos a la persona que llama, esto se puede usar para enumerar básicamente la base de datos. He visto esto sucediendo recientemente. El mensaje de error se redujo a 30 caracteres y solo fue posible seleccionar una columna y una fila a la vez, pero aún así es posible enumerar todo el DB con él.

Otros han tocado con razón el motivo por el cual los detalles de MySQL no deben exponerse a través de la interfaz de usuario principal de un sitio web / aplicación en un servidor de producción.

Pero hay un problema más amplio, mucho más alto en juego cuando se muestran errores a un usuario final como este:

Básicamente, telegrafía la idea de que el servidor / sitio está mal administrado.

Lo que significa que eres un objetivo más preciso para la piratería no por el contenido de los detalles, sino porque los detalles se han expuesto para comenzar.

Su actitud como desarrollador de aplicaciones, administrador de sistemas y demás, es hacer que su producto final pueda fallar con gracia de alguna manera que no exponga los "huesos" de la arquitectura del sistema, pero de alguna manera le transmita algunos datos útiles de depuración.

Si su aplicación está diseñada correctamente, mostrar el texto de los mensajes de error no debería ser un problema de seguridad. Si lo fuera, significaría que su seguridad depende de la ofuscación que se considera una mala práctica.

Dicho esto, la verdadera pregunta es: ¿cuál será la experiencia del usuario frente a mensajes como ese? Si su aplicación está destinada a usuarios promedio, recibirán un mensaje que no les brinda información útil: no entienden nada o no pueden hacer nada útil con ella. Peor aún, podrían pensar que esos desarrolladores perezosos ni siquiera procesaron correctamente sus errores , eso es lo que yo pensaría ...

Esa es la razón por la que el uso común es mostrar un mensaje más suave que diga que algo salió mal, vuelva a intentarlo y póngase en contacto con el servicio de asistencia si el error persiste, sin los detalles sangrientos. El mensaje de error completo solo se debe mostrar cuando la aplicación es ejecutada por el soporte en un modo especial porque los técnicos de soporte están interesados en los detalles del error.

Si realmente quieres hacer el mejor trabajo con errores:

• asegúrese de registrar el error y su contexto: fecha y hora, usuario, parámetros de la solicitud y, finalmente, los datos clave de la sesión para permitir que el soporte complete un ticket es algo que debe solucionarse en la aplicación
• solo muestra información externa al usuario
• agregue una forma específica para que el soporte acceda a todos los detalles de error cuando intentan reproducirlo; tiene un costo, pero será muy apreciado por los técnicos de soporte
• eventualmente, asigne un ID único al incidente y se lo mostrará al usuario

Esta última posibilidad solo tiene sentido para aplicaciones de alto valor con un número limitado de usuarios. Eso permitirá que el soporte técnico tenga inmediatamente todas las referencias para el problema cuando serán contactadas por el usuario. Pero también significa que está listo para responder individualmente por cualquier error que pueda ser realmente costoso para las aplicaciones normales .

Cualquier detalle técnico que pueda ser obtenido por un atacante puede ser aprovechado para explotar fallas o para obtener una mejor comprensión del sistema (para más adelante explotar fallas ...). En su caso, posiblemente podría aprovecharse para Inyección de SQL, pero también podría permitirle a uno identificar su DBMS (si utiliza consultas nativas con funciones propias de MySQL, por ejemplo), y luego probar las vulnerabilidades específicas de DBMS si el sistema no está parcheado.

Entonces, para responder a la pregunta: no, no es seguro divulgar sus consultas porque al hacerlo aumenta el riesgo de seguridad.

Como se menciona en los comentarios, la mejor práctica es ocultar dicha información en los entornos de producción.

Una práctica común (por ejemplo, los perfiles de Maven para desarrolladores de Java) es crear un proyecto para un entorno específico. El perfil de "producción" tendría una configuración diferente que no muestra los stacktraces en las respuestas html, sino que solo las registra en el backend.

Como nota adicional, mostrar mensajes de error técnico también podría "atraer" a atacantes aleatorios que desean perfeccionar sus habilidades al piratear cualquier sistema, ya que te hace parecer un objetivo débil.

Algunas respuestas han señalado que no es una buena práctica mostrar estos errores. Sin embargo, me centraré en tu pregunta: ¿es seguro?

Veamos un ejemplo de mensaje de error. Esta aplicación está escrita en Python y Flask:

Esto nos dice algunas cosas sobre la aplicación: está usando SQLite, la aplicación está en c:\jobs\token\ , hay una tabla data y algunas otras cosas.

No hay datos de usuario aquí. No revela el saldo de la cuenta de otra persona, los mensajes privados, nada de eso. Si bien es posible que un mensaje de error lo revele, en la práctica es raro.

Entonces, ¿qué tan confidenciales son los detalles de la aplicación? La principal preocupación aquí es hacer la vida más fácil para un atacante. Ciertas vulnerabilidades, como el recorrido de la ruta y la inyección de SQL, son más fáciles de explotar con un poco de fuga de información en los mensajes de error. Sin embargo, aún son explotables sin la fuga de información, es un trabajo más difícil. La restricción de los mensajes de error no detiene estos ataques. Sólo hace que la explotación sea un poco más difícil. El cambio es tan pequeño que ni siquiera lo considero cuando estoy evaluando el riesgo de una vulnerabilidad como la inyección SQL.

Entonces, la respuesta a tu pregunta es sí, es segura . No es la mejor práctica, pero de ninguna manera es particularmente insegura.

Dar detalles de la configuración de su base de datos generalmente es una mala idea. Los usuarios legítimos no deberían necesitar saberlo y los usuarios malintencionados pueden encontrar algo allí que de otra forma tendrían que hacer conjeturas.

Otras respuestas han detallado bastante bien qué tipo de riesgo puede suponer para su base de datos.

Mostrar el informe de errores también puede abrir un nuevo vector de ataque en su sitio web. Diga, ¿qué sucede si solicité el documento con ID <script>alert('XSS')</script> ? Probablemente no se encuentre uno en la base de datos y recibo el informe de errores. Los controladores de errores a menudo no son la parte más cuidadosamente construida de una base de código, por lo que es posible que haya logrado ejecutar un ataque XSS contra el sitio.

Los mensajes de error de sintaxis para las sentencias de SQL deberían nunca , ya que eso realmente ahorraría tiempo para el atacante que intenta explotar una vulnerabilidad de SQLi.