Non puoi. È sfortunato, ma non puoi. Qualunque cosa stia funzionando come client (salvo alcune situazioni che quasi certamente non riguardano il TPM) può, se qualcuno è sufficientemente motivato, essere completamente compreso. Qualcuno può smontarlo, emularlo, patcharlo - non c'è praticamente nulla che tu possa fare al riguardo.

Quello che devi fare non è cercare di autenticare il client, ma piuttosto di autenticare l'utente. Guarda OAuth2 / OpenID Connect / similar - falli accedere con gmail o facebook prima di utilizzare la tua app. Se si tratta di un processo in background, consenti loro di registrarsi sul tuo sito web (usando oauth2, ecc.) Per ottenere un apikey. Quel apikey è unico per loro, li identifica per te, quindi se vedi un abuso, puoi legarlo alla loro gmail / facebook / qualunque cosa.

Se non puoi farlo, bene, allora sei bloccato solo a rendere più difficile. Puoi sperare che non siano sufficientemente motivati per decompilare la tua app e ottenere il tuo algoritmo hash, ma a lungo termine non è un gioco vincente.

HashCash

Potresti incorporare la prova di lavoro nel sistema: usa qualcosa come HashCash per richiedere all'utente di spendere, diciamo, 1 secondo di tempo CPU per inviare messaggi al tuo server. Questo sistema potrebbe essere tanto semplice quanto richiedere all'utente di inviare un nonce con il messaggio in modo che quando il nonce e il messaggio vengono sottoposti a hash insieme, finisca con 5 0. Ci sarà un compromesso: se la tua app client utilizza l'1% di CPU, il tuo avversario sarà in grado di inviare 100 volte il numero di messaggi di un utente normale, che potrebbe essere troppi. Se il tuo cliente usa il 100% di cpu, il tuo avversario sarà in grado di inviare il normale tasso di messaggi, ma i tuoi utenti reali saranno infastiditi.

Quindi, il sistema completo sarebbe simile a questo:

Cliente:

Genera la richiesta GET nello stesso modo in cui la stai attualmente generando, ma con un campo extra chiamato Nonce. Hash la richiesta GET e vedi se termina in x numero di zeri. Se non finisce con x zero, scegli in modo casuale un nuovo Nonce e riprova. In caso affermativo, inviarlo al server.

Server:

Accetta solo richieste GET che, se sottoposte a hash, terminano con il numero corretto di zeri. Inoltre, accetta solo le richieste GET con data e ora negli ultimi cinque minuti e mantieni una tabella delle richieste GET accettate di recente e verifica le richieste GET in modo che ogni richiesta venga accettata solo una volta

Limita la velocità, semplice e semplice.

È necessario determinare l'importanza del servizio. Se si tratta di un servizio da cui dipende l'applicazione, è necessario implementare la sicurezza. Potrebbe assumere la forma di avere l'accesso dell'utente tramite il browser, quindi salvare un file nella propria directory home. La tua app leggerà quindi la chiave API dal file e firmerà tutte le sue richieste con essa.

Se si tratta di un tipo di servizio più analitico, non hai molta scelta. Anche Google Analytics conterrà dati di spam in esso. Innanzitutto concentrati sulla riduzione della quantità di spam prima di provare a eliminarli completamente. Se qualcuno invia 5+ richieste al minuto da un IP, bloccale temporaneamente. Prima istituisci un divieto di 5 minuti, poi 15, poi così via. Quando un IP viene bannato, registralo e contrassegna le altre voci che sono state fatte poco prima e dovresti essere in grado di filtrare quanti più dati possibile. Se dovessi andare ancora oltre e bloccare il tuo sito dietro un servizio come Cloudflare, potresti usare la loro API per bloccare l'indirizzo IP, assicurandoti che la richiesta non colpisca nemmeno il tuo server dopo che è stato bannato.

Tuttavia se il "troll user" ha accesso a una bot-net abbastanza grande, anche le grandi aziende sono suscettibili

Accettare solo un invio per indirizzo IP non è una soluzione molto efficace - gli indirizzi IP non sono staticamente legati alle persone. Il fingerprinting del dispositivo (in particolare se combinato con altri approcci come evercookie e ASN) fornisce un indicatore migliore di chi si trova dietro l'indirizzo IP. C'è qualche discussione su cosa appare essere lo stesso problema qui . Il modo in cui applicherebbe il fingerprinting a un'app è piuttosto diverso da un browser.

Tuttavia ciò che manca nella discussione e anche in questa domanda è qualsiasi descrizione di quale sia il valore nel servizio, né l'impatto delle persone che inviano più richieste quando ci si aspetta che ne facciano una sola. Considera questo sito. Chiunque può registrarsi per un account, ma non abbiamo il diritto di modificare le proposte di altre persone senza dimostrare che possiamo aggiungere valore al servizio nel suo complesso. Le azioni vengono attribuite e tutti hanno la possibilità di mostrare la loro [dis] approvazione e commento. Wikipedia ha un approccio simile, ma più formale, alla gestione dei contenuti. Un modo molto efficace per affrontare gli attacchi di amplificazione di sloloris e dns è semplicemente quello di avere la capacità di gestire il carico extra senza incidere sugli altri utenti. Ci sono dei limiti a ciò che è capace con questo approccio, ma se l'unico impatto qui è lo storage extra, quindi aggiungere più capacità non è poi così costoso (ma sei limitato dalla scelta di un back-end in sqlite).

Se la caratteristica di definizione di un attacco è un alto tasso di invio dallo stesso indirizzo IP o relativo allo stesso account, allora hai una base per rilevare automaticamente il comportamento e ridurre l'impatto sul tuo sito trattandoli in modo diverso - per esempio solo rispondendo con un valore casuale invece di hashing e memorizzazione.

Se hai fornito ulteriori informazioni su come l'attività di questa persona influisce sul tuo sito e sulla natura del servizio, potremmo forse dare consigli più specifici su una strategia più ampia.

Ho notato che in un commento hai menzionato che gli IP sono simili. In questo caso, puoi escludere l'intervallo IP che sembra utilizzare.

Se è dedicato, può usare IP al di fuori di tale intervallo. Come ha detto Crovers, la soluzione migliore è autenticare l'utente, usando qualcosa come Gmail, Facebook o SMS.

Puoi richiedere al cliente di lavorare, come ad esempio QuadmasterXLII suggerito con HashCash. Assicurati che il client stia facendo molto più lavoro del server e che il lavoro richiesto agli utenti non maliziosi sia accettabile.

Oppure puoi combattere una continua battaglia di patch per essere sempre un passo avanti. Queste sono le opzioni che vedo in ordine di cui vorrei provarle.

Suggerimento generale: tutto ciò che inserisci nel client può simulare.

I'd use something like a captcha, but it's just a background thread that routinely submits the get request, there is no user interaction with it at all.

Ma a meno che tu non stia facendo un virus, qualcuno lo imposta intenzionalmente. A quel punto, puoi farli registrare il client e inserire un CAPTCHA come parte del processo. (Ad esempio, ogni client riceve un token di sessione dal server, che memorizza solo se il CAPTCHA è stato compilato correttamente.)

Non esiste un numero infinito di indirizzi IP che è possibile utilizzare. In IPv4 dovrai vietare gli indirizzi IP utilizzati da uno spammer e contrassegnarne la sottorete. In IPv6 ti consigliamo di escludere /64 s e contrassegnarne la subnet.

Ad esempio, se 80.100.131.150 ti sta inviando spam, ti verrà vietato quell'indirizzo e flag 80.100.0.0/15 (su Linux whois 80.100.131.150 | grep ^route ti mostrerà). Spesso, gli indirizzi IP domestici vengono ruotati di notte e i proprietari di VPS possono ottenerne uno nuovo (selezionandone uno o a caso), ma l'ISP possiede un numero finito di sottoreti. In questo modo imponi allo spammer di agire per ottenere l'aggiornamento dell'indirizzo IP e, una volta fatto, probabilmente si troveranno ancora in una sottorete contrassegnata.

Le sottoreti con bandiere ottengono CAPTCHA in più. Non uno ma cinque CAPTCHA alla registrazione (o qualcosa del genere). Una volta che una sottorete raccoglie due o tre flag, interrompila completamente. Punti bonus se invii un'email all'indirizzo di abuso della sottorete.

Ci sono più risorse limitate che puoi fare con questo, come gli indirizzi email. Piccolo sforzo per gli utenti di attivare il proprio indirizzo di posta elettronica, ma uno spammer si stancherà di dover inserire venti CAPTCHA perché entrambi hanno la loro sottorete e il loro dominio di posta elettronica (ad es. Mail.ru).

Nota che ci saranno vittime. Chiunque utilizzi lo stesso ISP di uno spammer verrà anch'esso bannato (una volta che ha raccolto abbastanza bandiere).