Previene l'abuso sull'endpoint dell'API REST

Per la prima domanda, il tuo approccio mi sembra corretto. Si consuma un token nella voce sendsms che può essere generata solo dall'endpoint login . È anche possibile utilizzare un token generico creato dal login e non facilmente ipotizzabile (sarebbe equivalente a un ID di sessione generato da crittografia), utilizzato come chiave primaria per una tupla del database. Lì puoi memorizzare quello che vuoi (ad esempio il numero di SMS ancora permesso di essere inviato).

Puoi anche memorizzare lo "stato" in una variabile e proteggerlo usando, diciamo, HMAC, scambiandolo continuamente tra il server e il client, ma hai ancora bisogno di qualche stato del server da difendere contro riprodurre attacchi su endpoint non idempotenti; al minimo, è necessario un contatore incrementale per sessione.

Il secondo problema è più complicato e per prima cosa è necessario chiedersi quale sia la differenza di comportamento (vista dal server) tra l'app e la sua logica e un utente malintenzionato che invia richieste ripetute. Potresti far rispettare un ritardo minimo tra le richieste che è paragonabile alla massima velocità con cui l'app può essere guidata, in modo che non ci sia più un vantaggio nell'uso di trucchi piuttosto che nell'app.

Ecco un problema con il tuo approccio proposto. Se invii le richieste via HTTP, una terza parte può spiare il traffico e scegliere il token di autorizzazione. Quindi possono inviare le proprie richieste al punto finale utilizzando il token.

Soluzione: usa HTTPS anziché HTTP quando esegui l'autorizzazione iniziale per ottenere il token e ogni volta che utilizzi il token.

Per la tua seconda domanda, il problema è fondamentalmente intrattabile. Presumo che questi "punti" siano qualcosa che dovrebbe essere cambiato solo in base ad alcune regole che hai stabilito. A meno che le regole siano tali da poter rilevare cheats dal lato server sei bloccato. L'unico modo per risolverlo è implementare tutto ciò che è direttamente o indirettamente coinvolto nel punteggio sul lato server. Questo probabilmente sconfigge lo scopo del tuo gioco.

Ho notato che stai usando 127.0.0.1. Immagino che sia solo un segnaposto per il vero indirizzo IP.

In caso contrario, tieni presente che stai parlando a un servizio in esecuzione sul proprio computer / dispositivo dell'utente. Se l'utente ha accesso fisico e tempo / esperienza sufficienti, molto probabilmente può sovvertire qualsiasi controllo di accesso implementato nel servizio.

Lo stesso vale per qualsiasi logica lato client finalizzata a far rispettare le regole o a prevenire l'imbroglio.

(Ti sei mai chiesto perché gli MMO e simili hanno problemi con i cheat? Non è perché i venditori non provano. È perché è impossibile per sconfiggere i cheat nel software se i cheat controllano la piattaforma lato client in cui viene eseguito il software.)