Prevenir el abuso al punto final REST API

8

Pregunta 1

Tengo un punto final de API de inicio de sesión

http://127.0.0.1:8080/api/account/login

Comprueba si el número de teléfono ha sido validado. Si no, llamará

POST http://127.0.0.1:8080/api/account/sendsms  country_code=1, phone_number=1234567

¿Cómo puedo evitar el abuso al solicitar sms? (Costará dinero de mi parte. También tengo la función de aceleración)
Sólo quiero que se envíen SMS si /login ha fallado (en este momento se ha validado el correo electrónico)
La forma en que lo hago es enviar un encabezado personalizado X-TOKEN-SMS que actúa como un encabezado de autorización con el token jwt. El token jwt de X-TOKEN-SMS se crea en /login si el número de teléfono no está validado = Verdadero.
Cuando /sendsms decodifica el jwt sin error, continúe con la solicitud de sms. Si JWT se decodifica con un error, el front-end se redireccionará a /login .

¿Es este método una buena práctica?
¿Cómo permite que se acceda a un extremo de API solo si se ha accedido a un extremo?

Pregunta 2

Supongamos que tengo un punto final al que solo puede acceder un usuario autorizado

http://127.0.0.1:8080/api/account/points

El usuario puede obtener puntos (recuperar todos sus puntos) Puntos POST (crear un nuevo punto) o PATCH (actualizar un punto)

¿Cómo puedo evitar que un usuario autorizado abuse de POST / points? Podrían agregar puntos como les plazca, que no es lo que mi aplicación quiere que sea. Agregar puntos debe ser manejado por la lógica de la aplicación.

Si la API REST no debe consumir el punto de adición, crear una nueva fila directamente en la base de datos es más seguro.

Encontré una pregunta similar antes Asegurar el api de Rest del usuario autenticado Pero parece que no podía entenderlo.

    
pregunta momokjaaaaa 30.04.2016 - 00:50

2 respuestas

3

Para la primera pregunta, su enfoque me parece correcto. Usted consume un token en la entrada sendsms que solo puede generar el punto final login . También puede usar un token genérico creado por el inicio de sesión, y no es fácil de adivinar (sería equivalente a un ID de sesión generado criptográficamente), utilizado como clave principal para una tupla de base de datos. Allí puede almacenar lo que desee (por ejemplo, la cantidad de SMS que aún se pueden enviar).

También puede almacenar el "estado" en una variable y protegerlo utilizando, por ejemplo, HMAC, intercambiándolo continuamente entre el servidor y el cliente, pero aún necesita algunos estado del servidor para defenderse ataques de repetición en puntos finales no idempotentes; como mínimo, necesita un contador incremental por sesión.

El segundo problema es más complicado, y primero debe preguntarse cuál sería la diferencia de comportamiento (como la ve el servidor) entre la aplicación y su lógica, y un usuario malintencionado que envía solicitudes repetidas. Puede imponer un retraso mínimo entre solicitudes que sea comparable a la velocidad máxima a la que se puede dirigir la aplicación, de modo que ya no haya una ventaja en el uso de trucos en lugar de ir a través de la aplicación.

    
respondido por el LSerni 30.04.2016 - 01:27
3

Aquí hay un problema con el enfoque propuesto. Si envía las solicitudes a través de HTTP, un tercero puede detectar el tráfico y seleccionar el token de autorización. Luego, podrían enviar sus propias solicitudes al punto final utilizando el token.

Solución: use HTTPS en lugar de HTTP cuando realice la autorización inicial para obtener el token, y siempre que use el token.

Para su segunda pregunta, el problema es básicamente intratable. Supongo que estos "puntos" son algo que solo debe cambiarse de acuerdo con algunas reglas que usted ha establecido. A menos que las reglas sean tales, puede detectar trucos desde el lado del servidor que están bloqueados. La única forma de resolverlo es implementar todo lo que esté directa o indirectamente involucrado con la puntuación en el lado del servidor. Eso probablemente derrote el propósito de tu juego.

Observo que estás usando 127.0.0.1. Supongo que es solo un marcador de posición para la dirección IP real.

Pero si no es así, tenga en cuenta que está hablando con un servicio que se ejecuta en la propia computadora / dispositivo del usuario. Si el usuario tiene acceso físico y suficiente tiempo / experiencia, lo más probable es que él / ella pueda subvertir cualquier control de acceso que implemente en el servicio.

Lo mismo se aplica a cualquier lógica del lado del cliente dirigida a hacer cumplir las reglas o evitar el engaño.

(¿Alguna vez te has preguntado por qué los MMO y similares tienen problemas con los tramposos? No es porque los vendedores no lo intentan. Es porque es imposible derrotar a los tramposos en el software si el los tramposos controlan la plataforma del lado del cliente donde se ejecuta el software.)

    
respondido por el Stephen C 30.04.2016 - 04:39

Lea otras preguntas en las etiquetas