¿Debe una aplicación web devolver verdaderos errores de http?

Yo diría que no luchar contra los RFC en un vano intento de proporcionar seguridad a través de la oscuridad, crearán más dolores de cabeza cuando alguien se conecte a su API y esté recibiendo 200 códigos cuando el servidor realmente esté lanzando 500.

Honestamente: si de alguna manera obtiene una lista de todas mis firmas de API, todavía no me importará y devolveré 403s todo el día. Incluso en una API abierta, sus 500 mensajes deberían ser lo suficientemente genéricos como para que no sepan realmente qué es lo que está sucediendo, aparte de que "al servidor no le gustó la entrada, siga las especificaciones, etc., etc.".

Aunque no devolver los códigos puede proporcionar cierta medida de seguridad a través de la oscuridad, cada uno de ellos es una cosa útil que se debe conocer como usuario. Si su servidor retrocede a 500, sé como usuario legítimo que no es mi culpa, en lugar de rascarme la cabeza con un falso 404.

Considere la posibilidad de modificar esos mensajes de error solo cuando sepa que hay una fuga de algún tipo que desea evitar (404 para una página de usuario que no está autorizado a conocer, vs. 403 impediría la enumeración). Alterar al por mayor todo tiene más inconvenientes que beneficios.

Al igual que los otros encuestados hasta el momento, estoy de acuerdo en que una pequeña cantidad de seguridad por oscuridad no supera el beneficio de devolver un código de respuesta semánticamente significativo. Además de informar al usuario del estado, es una gran ayuda tener datos significativos registrados en los registros para diagnosticar errores, problemas de rendimiento y analizar la seguridad.

Sin embargo, una advertencia es para un error 401: esto generalmente hará que el navegador solicite una contraseña que, en ausencia de una directiva de resumen, puede enviarse en texto claro: si la solicitud no está autorizada y (como en la mayoría de los casos). casos) la autenticación se maneja mediante el código que se ejecuta en la parte superior del servidor web, luego se usa un código diferente (¿soy una tetera?).

De hecho, iría más lejos y sugeriría que piense detenidamente si puede transmitir más información utilizando los códigos de estado indefinidos.

Supongo que ya conoce el hábito de MSIE de reemplazando HTML devuelto con códigos que no sean 2XX.

Hay dos aspectos que debe considerar aquí y usted debe tomar una decisión en función de lo que está protegiendo y de las vulnerabilidades que pueden exponer los códigos de error. Por un lado, los mensajes de error explícitos facilitan la depuración y me refiero a la depuración basada en la experiencia real del usuario. Los errores más peligrosos son los que nunca experimentas hasta que el sistema se pone en marcha. Cuanto más rápido pueda aplastarlos, tanto mejor desde una perspectiva de seguridad como de negocio.

En el lado más aterrador del mundo, las amenazas (sombreros negros) que hay ahora son muy sofisticadas. Harán una huella digital de su sistema operativo, red, lenguajes de programación, bibliotecas y horas de funcionamiento máximas antes de lanzar un ataque. Darles más información es peligroso, especialmente si sus sistemas no se actualizan y actualizan con frecuencia. Permitir una amenaza para explorar las áreas sensibles con errores de autenticación aumentará su riesgo.

Dicho esto, tiendo a estar de acuerdo con Jeff y StrangeWill. La información con la que se retendría probablemente será utilizada con más frecuencia por su propio equipo que por el sombrero negro oportunista. A menos que lo que esté protegiendo tenga un alto valor (más que solo las direcciones de correo electrónico y las contraseñas), la capacidad de corregir rápidamente los errores es más importante para el negocio que la negación de una pequeña parte de información a los sombreros negros (todavía obtendrán una mucho de todos modos).