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

11

Un usuario malintencionado puede usar la información de excepciones y errores para mapear la API de una aplicación web, por lo que es habitual ver las listas de verificación de seguridad para recomendar que solo se envíe un mensaje de tipo "Comuníquese con su administrador".

Por otra parte, se nos recomienda utilizar estándares HTTP, que recomiendan errores como

  • 400 - solicitud incorrecta
  • 401 - no autorizado
  • 403 - prohibido
  • 405 - método no permitido
  • 500 - error interno
  • 501 - no implementado

Todos parecen proporcionar cierta información sobre la API, es decir, que existe tal invocación y que, aunque su ataque estuvo cerca de una solicitud con el formato correcto, no fue lo suficientemente cerca.

¿Se deberían traducir todas estas solicitudes HTTP al mismo mensaje de error, o debería prevalecer el cumplimiento de las normas?

ACTUALIZACIÓN : como desarrollador de aplicaciones, personalmente prefiero los mensajes de excepción bastante ricos y no me gusta que la mayoría de las aplicaciones en las que trabajo devuelvan 200 para todo lo que devuelve la aplicación y solo devuelva errores que no sean 200 cuando ASP.NET o IIS tienen ganas de devolver un error que no es 200.

    
pregunta MatthewMartin 21.11.2011 - 19:58
fuente

4 respuestas

13

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.".

    
respondido por el StrangeWill 21.11.2011 - 20:49
fuente
10

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.

    
respondido por el Jeff Ferland 21.11.2011 - 20:39
fuente
3

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.

    
respondido por el symcbean 22.11.2011 - 12:42
fuente
2

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).

    
respondido por el this.josh 22.11.2011 - 09:41
fuente

Lea otras preguntas en las etiquetas