Enumeración de datos confidenciales mediante códigos de error HTTP

2

Supongamos que hay un sitio web con una API que admite la siguiente llamada REST en la que el usuario autenticado Alice puede enviar un mensaje a Bob al usuario registrado que registró en nuestro sitio (hipotéticamente hablando, por el bien de este ejemplo) ):

curl --header "Authorization: JWT $someTokenForAuthz" \
     --header "Content-Type: application/json" \
     --request POST \
     --data '{"phone":"+43 123 456","msg":"some text"}'
     http://example.com/text/send

Supongamos que clasificamos el número de teléfono como datos confidenciales (PII) y supongamos que la API devuelve la siguiente respuesta en caso de que se envíe un número de teléfono que no se haya registrado en el sitio:

{"error": {"code":404,"message":"Phone number not found"}}

Imagínese a Eve escribiendo un guión que recorre los números de teléfono celular del +43 000 001 al +43 999 999 (ignorando las limitaciones de los números de teléfono del mundo real). Con el código de error y después de 1 000 000 iteraciones de su script, Eve ha enumerado todos los números registrados en el sitio y puede, por ejemplo, orientar los usuarios del sitio de una manera más específica.

¿Es un problema de seguridad devolver un código de error HTTP 404 cuando no se encontraron datos confidenciales como un número de teléfono celular en nuestro sistema? ¿Cuál sería una mejor manera en términos de manejo de errores (como ¿Una estrategia de copia de seguridad en caso de que los mecanismos de detección / límites de solicitud que ya están implementados puedan fallar) para evitar este descubrimiento de datos confidenciales? ¿Un error 401 - not authorized más general o algo completamente diferente?

    
pregunta SeeYouInDisneyland 11.09.2018 - 12:57
fuente

2 respuestas

2

Entonces, la vulnerabilidad es que devolver un código de error permite la enumeración de los números de teléfono registrados. Si permitir que se divulguen los números registrados es incorrecto, entonces este es un problema de seguridad.

  

Un 401 más general - error no autorizado

No, acabas de cambiar el texto, no has cambiado el comportamiento.

Hay muchas cosas que podría hacer para que la solución sea más segura, pero no tenemos ninguna base para saber cuáles son las adecuadas para su modelo ficticio, por ejemplo,

  • informe siempre el éxito
  • no utilice números de teléfono: use un identificador sustituto (con una entropía mucho mayor) y solicite al cliente que mantenga sus tablas de búsqueda
  • requiere acceso autenticado y revoca ese acceso en función de las tasas de falla
  • siembra los datos con honeypots y revoca el acceso de los clientes cuando intenta usar uno
  • limita la velocidad a la que un cliente puede realizar solicitudes
  • cargar al cliente por cada POST
  • requiere que los destinatarios opten por recibir mensajes de un cliente determinado; devuelva el mismo error para un número faltante que el que no tiene permiso
  • ...
      

    suponiendo que los límites de solicitud / mecanismos de detección ya están en su lugar

¿Entonces está diciendo que tiene mecanismos de protección establecidos, pero no protegen contra la enumeración? Entonces tu pregunta es un oxímoron.

    
respondido por el symcbean 11.09.2018 - 13:49
fuente
1

Su interfaz podría decirle al usuario solo los mensajes de estado que se refieren a la interfaz. ¿Solicitud recibida? Si es así, dile. Si la validación falla, infórmales. Nada más. Si el backend no puede entregar el mensaje por cualquier motivo, no se debe informar a la interfaz.

Devolver solo algo como {"status": "success", "message": "Received"} es suficiente. Eva no necesita saber si el número existe o no. Si Eve envía un número no válido (no válido, no está registrado), podría lanzar {"status": "error", "message": "Invalid number"} para que pueda corregir el error tipográfico e intentarlo nuevamente.

    
respondido por el ThoriumBR 11.09.2018 - 15:20
fuente

Lea otras preguntas en las etiquetas