it-swarm-eu.dev

Garantire il servizio Web a cui accedono solo le applicazioni autorizzate

Prefazione

La mia app mobile consente agli utenti di creare account sul mio servizio. Oltre a poter accedere con provider di autenticazione esterni, come Facebook, voglio offrire all'utente la possibilità di creare un account utilizzando un indirizzo e-mail.

Normalmente, tutte le chiamate al mio servizio web sono autenticate tramite autenticazione di base su HTTPS. Tuttavia, la funzione di creazione dell'account (anche su HTTPS) non ha alcuna autenticazione, poiché l'utente non ha ancora credenziali.

Se stessi scrivendo un sito Web, utilizzerei Captcha per impedire che il mio database venisse riempito con account fasulli tramite script.

Domanda

Come posso verificare che le richieste di nuovi utenti provengano da un'istanza della mia applicazione e non da un bot?

Se tutti i dati vengono inviati tramite HTTPS, è sufficiente che l'applicazione disponga di una password memorizzata per dire "hey, sono io!"? Quali sono le migliori pratiche per fare qualcosa del genere?

Elaborazione

Il server è scritto in Java utilizzando Spring Framework e Spring Security. È ospitato su App Engine. Il costo è un problema (sia di rete che di calcolo). L'app è un gioco mobile. non memorizzo informazioni sensibili come i numeri di carta di credito. Tuttavia, tengo traccia degli acquisti degli utenti sui negozi Apple e Android. La mia più grande preoccupazione è l'esperienza del giocatore. Non voglio che un hacker distrugga il sistema e rovini il divertimento di qualcuno, ma devo anche assicurarmi che il giocatore debba affrontare il minor numero di ostacoli possibile durante la creazione di un account.

Aggiornamento/Chiarimento

Sto cercando un modo per garantire che tutte le chiamate al servizio provengano da un'istanza della mia applicazione. Gli account utente sono già protetti perché il servizio senza stato richiede che invii le proprie credenziali ad ogni richiesta. Non ci sono sessioni né cookie.

Devo bloccare lo spam bot sulle chiamate non protette, come creare un nuovo account. Non riesco a usare captcha perché non si adatta al flusso dell'applicazione.

33
sbsmith

La linea di fondo è che dovrai incorporare un segreto nella tua app. È una sfortunata verità che DRM (che è più o meno ciò che stai cercando di ottenere) è impossibile. Una persona con accesso alla tua app sarà sempre in grado di recuperare il segreto incorporato, indipendentemente da ciò che fai per proteggerlo.

Detto questo, ci sono molte cose che puoi fare per rendere il tuo segreto incorporato molto difficile da recuperare.

  • Costruiscilo in fase di esecuzione - Non archiviare il segreto in una stringa o in un file di configurazione in nessun punto della tua app. Invece derivalo da una serie di calcoli in fase di esecuzione. Ciò impedisce agli aggressori di navigare semplicemente nella tua app con un hexeditor.

  • Non inviarlo mai via cavo - Usa un sistema di risposta alla sfida di qualche tipo con un nonce> 128 bit, in questo modo un utente malintenzionato non può mitigare il flusso SSL ( che è facile quando controlla il dispositivo mobile ricordare) e vedere il segreto in chiaro.

In ogni caso, prova a trovare un meccanismo collaudato di codifica delle chiavi e un protocollo di autenticazione. Non arrotolare il tuo.

26
lynks

Per lo più non puoi verificare che questa sia "la tua app": reverse engineering funziona, quindi chiunque abbia accesso alla tua app (ad esempio può scaricarla sul suo telefono) può strappare le sue viscere ed emularla con la sua PC. @Lynks ti dà alcuni suggerimenti su come questo reverse engineering possa essere reso uno sforzo più frustrante, ma non illuderti: se l'attaccante è sufficientemente motivato, questi meccanismi lo rallenteranno al massimo di un paio di giorni.


Quando non c'è una buona risposta per una domanda, può essere utile spostare il terreno in modo che la domanda cambi. Qui, il problema principale nel cercare di assicurarsi che "la tua app" sia ciò che gira sul lato client è che esiste qualcosa come "la tua app": se qualcuno apre i contenuti di quell'app, impara tutto ciò che è per conoscere tutte le istanze di quell'app ovunque.

Quindi ecco un tentativo di soluzione al tuo problema. Contrassegna ogni istanza dell'app con un valore distinto. "Tagging" qui significa che quando l'utente scarica l'app, un token viene incorporato nell'app e viene creato un nuovo valore token per ogni download. In modo che ogni utente ottenga la propria app con token. L'idea è che il token dovrà essere presentato al tuo server per la creazione dell'account e se il tuo server vede troppe richieste con lo stesso token, allora può respingerle automaticamente, vietando quel token specifico.

Quindi, per continuare a creare automaticamente molti account, l'utente malintenzionato dovrebbe anche automatizzare il download di nuove istanze dell'app (ognuna con il proprio valore token) e il recupero del valore token dall'app scaricata. Supponendo che il tuo server sia all'altro capo del download dell'app, puoi anche rilevare tale download di massa e bloccarlo da lì.

Affinché questo schema funzioni, devi essere in grado di creare valori token sul server di download delle app, su richiesta (ciò potrebbe essere difficile da configurare con il sistema di installazione delle app su smartphone esistenti, tuttavia) e tale che il server di creazione dell'account possa decidere se un valore di token è autentico o meno. HMAC è lo strumento crittografico giusto per questo.


Tieni presente che questo tipo di soluzione non è assolutamente perfetto. Questi sono giochi e trucchi per "alzare il tiro" per l'attaccante: se progettate e installate un sistema come quello che descrivo, un attaccante di successo dovrà automatizzare il download dell'app da molti indirizzi IP distinti, da tenere sotto controllo della tua euristica per rilevare tali cose; quindi automatizzare anche il reverse engineering per recuperare i valori dei token (utilizzare le tecniche spiegate da @Lynks per quello); quindi inoltrare i valori ai suoi robot che creano account. Tutto ciò è ancora teoricamente fattibile: dopo tutto, utenti umani può scaricare l'app e creare account, e non c'è modo di fare davvero la differenza, dall'esterno, tra un utente umano medio , uno scimpanzé e un bot.

Ma se riesci a rendere l'attacco sufficientemente complesso che l'attaccante lo ritiene "non degno dello sforzo", allora vinci.

17
Tom Leek

Se stessi scrivendo un sito Web, utilizzerei Captcha per impedire che il mio database venisse riempito con account fasulli tramite script.

Quindi includilo nell'API. Quando un utente desidera creare un account:

  1. Il client richiede un CAPTCHA.
  2. Il server genera un CAPTCHA, lo memorizza e invia una copia al client.
  3. Il cliente presenta il modulo di creazione dell'account, insieme al CAPTCHA.
  4. L'utente compila il modulo e risponde al CAPTCHA.
  5. Il client richiede la creazione del nuovo account e invia la risposta CAPTCHA con quella richiesta.

    • Se la risposta CAPTCHA è errata, il server elimina la sua copia di CAPTCHA (quindi il client non può riprovare) e risponde con un errore.

Puoi anche usare qualcosa come HashCash per rendere più difficile per qualcuno montare un attacco a forza bruta, assicurati solo che HashCash possa essere generato più velocemente di quanto un utente possa ragionevolmente completare il modulo.

4
Brendan Long

Ciò di cui hai bisogno è un'autenticazione dell'applicazione simile. È lo stesso concetto dell'autenticazione che fai per le chiamate API con siti come Twitter, Facebook e Foursquare. Non consentono a nessuno solo di interrogare la propria API. Invece, generano una chiave API e un segreto API per la tua app. Se l'applicazione presenta tali chiavi al server, è consentito utilizzare le loro API.

0
AdnanG

Se vuoi assicurarti che le persone utilizzino l'API solo attraverso la tua app, dovrai cambiare periodicamente tutti gli endpoint e anche cambiarli nella tua app client. Chiunque abbia creato la propria app client utilizzando l'API verrà lasciato con un'app client che non funziona. Ora potrebbero ricostruire nuovamente la loro app con gli endpoint API corretti, ma se continui a modificarli, alla fine si arrenderanno.

Un'alternativa potrebbe anche essere avere sia i vecchi endpoint API che restituiscono un messaggio di errore quando qualcuno tenta di chiamarli sia i nuovi (modificati) endpoint API utilizzati dall'app client aggiornata. Escludere tutti gli indirizzi IP che utilizzano ancora i vecchi endpoint API in modo che quando l'hacker/ladro aggiorna la sua app client di terze parti in modo che corrisponda agli endpoint aggiornati, non rimarrà più alcuna base di utenti perché tutti coloro che hanno utilizzato i vecchi endpoint API sono ora vietati. Questo scoraggerà anche quella persona dal continuare a rubare i tuoi dati mostrandoli nella sua app client

0
Maurice