Evitar el reenvío y la repetición de ataques mediante el uso del cliente en la API REST

Question

Evitar el reenvío y la repetición de ataques mediante el uso del cliente en la API REST

#1 de Jonah Benton (5 votos)
#2 de ClintM (-1 votos)

5

Tengo un backend API REST que tiene HTTPS (y HTTP bloqueado) y uso JWT como mecanismo de autenticación. El lado del cliente es la aplicación iOS / Android. Quiero agregar una capa de protección en la API crítica mediante el uso del cliente para prevenir (en su mayoría) la reenvío (llamar involuntariamente a la misma API dos veces debido a una mala red / IU) y (tal vez) un ataque de repetición. Los detalles actuales son los siguientes.

(Todas las llamadas REST son a través de HTTPS)

el cliente realiza una llamada a la API utilizando el nombre de usuario y la contraseña para intercambiar un JWT desde el lado del servidor
el cliente usa el JWT obtenido (encabezado HTTP) y realiza una subsecuente llamada de API al servidor
servidor backend, compruebe el JWT y ejecute la solicitud

El problema actual es que cualquier persona que pueda interceptar el paquete HTTP puede reproducir la llamada a la API. Además, en una situación de mala red, el cliente puede presionar el botón enviar / confirmar dos veces y volver a enviar la solicitud.

Lo que propongo es lo siguiente:

el cliente realiza una llamada a la API utilizando el nombre de usuario y la contraseña para intercambiar un JWT desde el lado del servidor
el cliente usa el JWT obtenido + un nonce generado por el cliente y realiza una llamada de API subsecuente al servidor backend.
el servidor backend comprueba primero el JWT y luego el nonce. Supongamos que tenemos una tienda de k-v con TTL como Redis.
Si el nonuce existe en Redis, rechazamos la solicitud. De lo contrario, aceptamos la solicitud y configuramos el nonuce en Redis con un TTL predefinido (por ejemplo, ¿1hr?) Para que se rechace una repetición.

Tengo que admitir que tengo muy poco conocimiento sobre seguridad. ¿Quiero saber si esta propuesta es legítima? ¿O me falta algo importante? Si mi idea está bien, ¿cuál es el mejor algoritmo para generar el nonce? ¿Es necesario que el lado del servidor "decodifique" el nonce para ver si se ajusta al protocolo antes de compararlo con Redis?

rest api nonce

pregunta mingchuno 03.08.2016 - 05:02

fuente

2 respuestas

-1

(Todas las llamadas REST son a través de HTTPS)

Entonces ya estás protegido contra los ataques de reproducción.

respondido por el ClintM 27.02.2017 - 09:43

fuente

Lea otras preguntas en las etiquetas rest api nonce

proceso de arranque de TPM El software del módem USB instala autorun.inf parser, ¿existen riesgos?

score 5 · Accepted Answer

Un nonce del lado del cliente presenta tres dificultades:

¿cómo sabe el cliente cuándo generar un nuevo nonce? (¿Qué acciones constituyen una nueva solicitud para que se genere un nuevo nonce?)
¿cómo sabe el servidor qué es un nonce válido? ¿Un hipotético blob de 4gb suministrado por un atacante puede ser una excepción?
¿Cómo sabe el servidor la cantidad de nonces que debe conservar y por cuánto tiempo?

Un nonce proporcionado por el servidor proporciona dos ventajas:

menos para que el cliente haga
el servidor sabe qué esperar a continuación

El servidor no tiene que mantener un registro de todos los datos, solo el actual, y se puede eliminar cuando llegue la primera solicitud válida. Un nuevo nonce puede ser enviado con la respuesta.

Este modelo impone un modelo de interacción de una sola solicitud en vuelo. Si hubiera un deseo de múltiples solicitudes concurrentes, el servidor puede producir un bloque de nonces, pero el desafío nuevamente es que el cliente necesita un modelo para diferenciar entre solicitudes únicas, asegurando que cada acción del usuario no resulte en la extracción de un nuevo nonce. La piscina local. Esta dificultad debería sugerir la estructuración de la aplicación de manera tal que solo una solicitud no requerida esté en vuelo a la vez.