¿Son 500 respuestas o códigos de error específicos más seguros para los servicios REST?

Question

¿Son 500 respuestas o códigos de error específicos más seguros para los servicios REST?

#1 de gowenfawr (4 votos)
#2 de tylerl (2 votos)
#3 de Lucas Kauffman (1 votos)

8

Estoy creando una API REST para almacenar datos confidenciales de seguridad para mi cliente y socios de terceros.

Cada solicitud se valida utilizando un HMAC de ciertos datos que se ingresan en una clave temporal asignada por un corto tiempo después de que el usuario haya iniciado sesión. Por supuesto, todo se ejecuta sobre TLS. Cada solicitud se registra, junto con las claves de los datos devueltos, así como las claves de los datos que se habrían devuelto si la solicitud no se bloqueara por algún motivo.

Si los datos no están presentes, o si los datos en una ubicación pueden ser leídos por un usuario en particular, pero no se actualizan, o si la solicitud de actualización tiene un formato incorrecto, ¿debería el servidor devolver un mensaje de error significativo, o no?

Si el usuario no tiene permisos para realizar una acción, se debe devolver una respuesta 401 o 403, lo que indica que la solicitud falló debido a la falta de permisos para realizar la acción. Se pueden usar otros códigos de respuesta en el caso de que los datos tengan un formato incorrecto o los tipos de datos esperados no coincidan (enviar una cadena a un campo int, etc.). Básicamente, siga las buenas prácticas de REST / HTTP y registre todo, pero no proporcione ninguna información al usuario más allá de una pista básica sobre lo que salió mal.
Nunca le dé a nadie información, en caso de que pueda usarse contra el sistema de alguna manera. Solo devuelve un error 500, sin descripción de ningún tipo. Hay cierto nivel de desacuerdo en cuanto a si se debe o no devolver un 404, o si se debe devolver una respuesta vacía o un error 500 en su lugar. Si un desarrollador externo se encuentra con estas respuestas y no entiende por qué, debe comunicarse con nuestra empresa, hacer que alguien revise los registros y explique cómo realizar las solicitudes correctamente.

¿Alguien tiene experiencia "desde las trincheras" respecto a qué metodología tiene más sentido? De particular preocupación es cómo equilibrar la seguridad con la usabilidad y las solicitudes de soporte.

http rest

pregunta drz 18.07.2013 - 15:31

fuente

3 respuestas

2

Evitaría el error 401 , ya que activa el navegador para mostrar un cuadro de inicio de sesión de autenticación HTTP. Esto es molesto y confunde a sus usuarios.

Aparte de eso, devuelva cualquier código de error que desee, solo tenga en cuenta que ciertos clientes harán ciertas cosas con su código de respuesta.

Por ejemplo, un 500 o 403 puede evitar que los motores de búsqueda indexen su respuesta, mientras que un 200 puede no hacerlo. El código de error en sí no revela nada de seguridad. Cualquier cosa en el rango 4xx dice que "el cliente hizo algo mal", mientras que cualquier cosa en el rango 5xx dice que "el servidor hizo algo mal".

respondido por el tylerl 19.07.2013 - 01:50

fuente

1

En caso de un servicio reparador, combinaría ambas opciones. Pero acabo de devolver 401 o 403 (no los distingo) y simplemente cometo un error genérico para 404 y 500, usaría 200 en lugar de un mensaje personalizado en lugar de 404 o 500.

respondido por el Lucas Kauffman 18.07.2013 - 15:48

fuente

Lea otras preguntas en las etiquetas http rest

¿Cómo protegen los sistemas contra un certificado de firma de código robado después de que el certificado expira? ¿Qué se considera un método aceptable y seguro de conexión remota a un sistema Linux?

score 4 · Accepted Answer

Versión corta:

Sea lo suficientemente informativo para apoyar a los usuarios legítimos de su aplicación, pero no más que eso.

Versión larga:

En primer lugar, no hay una respuesta única para esto, ya que depende del contexto de la aplicación. Si está lanzando una API de código abierto para que su producto permita a las personas escribir clientes, entonces querrá inclinarse en la dirección de proporcionar comentarios útiles para que puedan depurar su código y escribir controladores de errores útiles. Si está lanzando software de cliente de código cerrado para interactuar con su servidor de código cerrado, entonces puede ser un poco más restrictivo, porque solo se está impactando a usted mismo.

En segundo lugar, el modelo REST implica en parte que devolverá códigos HTTP con significado semántico (p. ej., 404 para "No encontrado", no solo 500 para todo). Por supuesto, REST es solo una forma de hacer las cosas, por lo que no es como si el auditor de REST te golpeara los nudillos si no lo haces, pero si estás usando un modelo, debes tener en cuenta que tiene razones para ser diseñado como tal. es.

En tercer lugar, el enfoque de seguridad más importante que puede tener es el contenido de los mensajes de error, no el significante. Devolver un 404, 403, 405, 502 o 503 es bueno ya que ayuda al punto final a determinar, aproximadamente , lo que salió mal. Por otra parte, devolver un seguimiento de la pila de su servidor Tomcat está muy por encima de la línea, y probablemente sea el predeterminado, ¡así que tenga cuidado!

Finalmente, mi experiencia "desde las trincheras" fue como la describí: devolver el código de error HTTP correcto, pero no te enfades, "503" dice "Servicio no disponible" y eso es todo. Para las cosas que no son problemas de nivel HTTP, devolvemos un 200 con un código de error de nivel de aplicación corto. Los códigos son numéricos y se pueden encontrar en la API y, por lo tanto, brindan cierta información a "un atacante"; aquí tenían la contraseña incorrecta, aquí tenían demasiadas conexiones concurrentes, aquí tenían "contenido objetable". Sí, eso le proporciona a un atacante una forma de mapear el sistema. El valor de tener un sistema que puede ser depurado por y para usuarios legítimos supera el beneficio de seguridad obtenido al ofuscar errores con un valor de retorno genérico. Por ejemplo, estoy dispuesto a apostar que un atacante inteligente podría diferenciar entre error de autenticación y violación WAF prestando mucha atención a la latencia de ida y vuelta, por lo que no estoy perdiendo todo lo suficiente dándole a él en un código de error.