¿Debo devolver un código de error significativo en caso de un error interno?

  

¿Qué práctica es mejor?

Depende de tus necesidades. No hay "seguro" o "no seguro", solo "lo suficientemente seguro para mis necesidades". Lo que es mejor depende de su disposición particular de riesgo / beneficio. Como tal, rara vez es una pregunta que se pueda responder en un contexto de seguridad.

  

¿Devolver códigos de error internos específicos puede ayudar a los atacantes en sus intentos de penetración?

Probablemente no. Ciertamente, no deberías devolver rastreos de pila o similares, pero una descripción vaga de error es probablemente poco probable que ayude a un posible atacante. Sin embargo, es probable que una descripción de error imprecisa también sea muy útil durante la depuración. Como resultado voy a hacer la pregunta obvia:

¿No has iniciado sesión en tu sistema?

Por ejemplo, en mis llamadas a la API, si hay un error en la producción, simplemente devuelvo (un documento JSON) que dice "Error interno" junto con un código de estado 500. Esto funciona bien para nuestros desarrolladores front-end. Cuando ven que simplemente se detienen y vienen a molestarme porque saben que el problema no está de su lado. Por mi parte, simplemente busco en los registros de mi servidor que me dicen exactamente qué sucedió. No hay nada que pueda filtrarse a personas externas, y tengo toda la información de depuración que necesito para solucionar cualquier problema.

En resumen, parece que lo que necesita es un registro detallado al que solo se puede acceder internamente.

Puedes ocultar los errores usando hash / hmac. Una opción sería tener la clave secreta K codificada en la aplicación (o en un archivo si usted es pedante, o si la aplicación está ampliamente distribuida). En caso de error, genere el token aleatorio T, luego muestre el error como HMAC (K, T + error_code);

Al depurar, solo use una utilidad simple para probar todos los errores posibles y ver cuál generó el HMAC. Esto oculta el error suficiente para que el usuario no sepa qué error fue, pero aún así no permite una depuración demasiado difícil.

PS: También puede ayudar el uso de códigos de error no secuenciales.

Sí, sí, devolver errores significativos

La seguridad es bastante difícil. Facilita la experiencia de desarrollador o usuario. En este caso, la compensación es mínima.

  

¿Devolver códigos de error internos específicos puede ayudar a los atacantes en sus intentos de penetración?

Sí, pero (con suerte) no en una medida significativa.

¿Cómo puede hacerte daño el mensaje de error detallado?

En realidad, ninguna de tus mitigaciones previene algunos ataques de tiempo. Aquí es un simple ataque de tiempo. Supongamos que está comparando una cadena de contraseña con una cadena de contraseña como esta:

$password = "bobcat"

La forma en que la computadora comprueba esto es:

for char1 in $password: for char2 in "bobcat": if char1 != char2: break

Ahora, si envío la contraseña "p" y falla más lentamente que si envío la contraseña "a", sabré que el primer carácter es "p".

Ahora solo necesito recorrer el resto del alfabeto hasta que obtenga el resto de los caracteres.

Si tus errores son resistentes a los ataques de tiempo, no te preocupes por la verbosidad.