Divulgación y códigos de estado HTTP

Question

Divulgación y códigos de estado HTTP

#1 de ifm (3 votos)
#2 de wireghoul (1 votos)

2

Descargo de responsabilidad: sí, he comprobado la ¿Qué códigos de estado HTTP son interesantes desde el punto de vista de seguridad? que suena relevante pero no del todo.

En estos días se supone que es una buena práctica no divulgar datos adicionales para usuarios no autenticados. Por ejemplo: direcciones de correo electrónico para la función "contraseña olvidada": cuando en lugar de decir "este correo electrónico no está registrado", le informamos que un usuario no está allí o que siempre devuelve el mismo mensaje como "revise su correo electrónico con el enlace para restablecer la contraseña ".

Hasta ahora todo bien.

Pero, ¿qué pasa con los códigos de estado HTTP, más detalles: para 404 vs 403.

Supongamos que tienes un área segura donde varias personas tienen acceso diferente. Digamos que es una gestión de usuarios para múltiples organizaciones.

Y si tiene una clave principal basada en una secuencia para los usuarios que se usa en el enlace al perfil del usuario, por ejemplo: /admin/users/42 , entonces puede iterar sobre el contador y comparar el código de respuesta de estado 404, para el que no existe, 403 para Los existentes determinan cuántos usuarios hay.

Es un ejemplo simple y creo que hay muchas cosas similares en todo.

Entonces, la pregunta: ¿deberíamos preferir la seguridad sobre la semántica y usar solo 403 (o 404) exclusivamente en todos los casos?

http disclosure

pregunta zerkms 12.04.2015 - 23:46

fuente

2 respuestas

1

Es un caso de usabilidad contra seguridad "implícita". Al hacer que las solicitudes tengan el mismo código de respuesta, un usuario perdió la capacidad de determinar si "el sitio web no funciona" debido a que escribieron la URL incorrecta o la contraseña incorrecta.

Como el valor del código de respuesta en sí no es una necesidad para que HTTP funcione, o incluso directamente relacionado con la URL solicitada. El atacante simplemente transferiría el inicio de sesión del escáner / ataque para operar en el cuerpo de la respuesta en lugar del encabezado, al igual que lo haría cuando explotara la inyección ciega de SQL.

En resumen, está incrementando la complejidad de la resolución de problemas y degradando la experiencia del usuario del sitio web para obtener una ganancia insignificante en "seguridad". En general, el aumento del costo financiero en la implementación y el soporte de estos cambios probablemente superará cualquier beneficio.

respondido por el wireghoul 13.04.2015 - 04:03

fuente

Lea otras preguntas en las etiquetas http disclosure

Cómo administrar una red infectada conocida ¿Es posible enviar dinero de manera segura a través de Paypal en redes wifi públicas? [duplicar]

score 3 · Accepted Answer

Prácticamente respondió su propia pregunta. Es completamente viable usar una respuesta simple para fortalecer su sistema contra un intento de análisis.

Otra opción podría ser: Use un UUID aleatorio para identificar a sus usuarios públicamente y mantener la clave principal solo para uso interno. Un UUID de 16 caracteres debería ser suficiente para mitigar este tipo de ataque.

Finalmente, debe considerar registrar todas las solicitudes fallidas para obtener información de los usuarios (403, 404).

Ahora, What method is better for your situation? es algo que debes decidir, considera los siguientes puntos:

Si su sistema ya está en fase de producción, podría ser mejor hacer un pequeño parche para formalizar todas las solicitudes fallidas del usuario a una respuesta 403/404.
Si está en la fase de diseño, puede optar por la segunda Opción y construir un sistema endurecido para sus usuarios.