Prevenire l'accesso illegale al servizio web

2

Vorrei iniziare dicendo che ho letto altre domande su StackExchange relative a questo problema e che non erano in grado di rispondere alla mia domanda. Ho la sensazione che questo possa essere un problema irrisolvibile, ma mi chiedo se forse c'è un mezzo felice che soddisferà le mie esigenze.

Ho un'applicazione Android. Tuttavia, non è basato sul login nel senso tradizionale del fatto che gli utenti non si iscrivano con una e-mail o altro. Creiamo automaticamente un account per loro con un UUID generato casualmente come "accesso" al servizio. Per ottenere questo UUID, l'applicazione Android invia una richiesta a un servizio web che indica che si tratta di un nuovo utente che ha appena installato l'applicazione. Il servizio web restituisce quindi un UUID che verrà utilizzato per ulteriori accessi all'applicazione. Il punto è fare in modo che le informazioni specifiche dell'utente possano ancora essere archiviate nel database, ma gli utenti non devono passare attraverso la seccatura di creare un account e accedere ogni volta.

Ovviamente, le richieste al webservice per altre azioni sono tutte limitate dall'avere un UUID valido. Tuttavia, il servizio web per la creazione dell'account non ha restrizioni, il che significa che un utente malintenzionato potrebbe inviare richieste GET ad esso da qualsiasi dispositivo per creare qualsiasi numero di utenti che desidera e riempire il database / server.

La mia domanda è, come può essere evitato? Comprendo il concetto di un segreto incorporato nell'applicazione Android per accedere al servizio web, ma sembra che qualsiasi segreto generato dal client possa essere facilmente ottenuto da un utente malintenzionato decompilando l'APK. Un'altra idea era di limitare l'accesso tramite l'indirizzo MAC, nel senso che solo gli indirizzi MAC con l'app installata potevano raggiungere l'URL del servizio web di creazione degli utenti. Ma a causa del MAC-spoofing, anche questa sembra una cattiva idea.

C'è un buon modo per avere un segreto generato dal cliente che non è facile da ottenere esaminando il codice sorgente? So che questa è una domanda molto difficile, ma se qualcuno ha qualche intuizione che sarebbe grandiosa.

    
posta Daniel Hipke 04.12.2014 - 01:44
fonte

2 risposte

0

However, the webservice for creating the account has no restrictions, meaning an attacker could spam GET requests to it from any device to create any number of users they want and flood the database/server.

My question is, how can this be avoided?

Puoi utilizzare una combinazione di restrizioni CAPTCHA e IP per evitare questo tipo di attacco.

Restrizioni IP:

Un IP univoco può creare un massimo di account X in un intervallo di tempo Y (Y secondi, o minuti, o ore, o giorni, ecc., solo tu puoi bilanciare la giusta quantità).

CAPTCHA:

I CAPTCHA sono comunemente usati nel tentativo di impedire la registrazione automatica dell'account, quindi è possibile richiedere un challenge-response CAPTCHA per creare un account.

Combina le restrizioni CAPTCHA e IP e hai finito.

Is there a good way to have a client-generated secret that isn't easy to obtain by examining source code?

Non ho capito la tua domanda.

1) Se vuoi proteggere il tuo server solo contro l'inondazione, la risposta è sopra.

2) Se si desidera proteggere i dati dell'utente, in modo che nessuno possa inviare richieste al server per ottenere le informazioni dell'utente con UUID X, è possibile creare un token casuale specifico per un UUID durante la creazione dell'account e memorizzarlo in un database crittografato su Android.

Modifica

Vedi il nuovo "No CAPTCHA reCAPTCHA".

link

Indolore per i tuoi utenti, efficace per te.

    
risposta data 04.12.2014 - 04:13
fonte
-1

However, it's not login-based in the traditional sense that users don't sign up with an email or anything. We just automatically create an account for them with some randomly generated UUID as their "login" to the service.

Se stai solo permettendo a QUALSIASI utente di creare un account con la tua applicazione, senza fornire alcuna informazione personale, è molto probabile che la tua applicazione venga spammata con un gran numero di richieste per creare nuovi utenti.

The point of this is to make it so that user specific information can still be stored in the database, but users don't have to go through the hassle of creating an account and logging in every time.

In realtà, questo è un po 'confuso. Che cosa sono esattamente queste informazioni specifiche dell'utente? Da dove viene se l'utente non si è mai registrato con la tua app? Se è qualcosa di unico, come un ID e-mail o un numero di telefono mappato con l'UUID assegnato dall'utente, queste informazioni univoche possono essere utilizzate per una semplice autenticazione Challenge-Response, che può essenzialmente fermare la truffa. Il fatto che l'applicazione stia consentendo agli utenti di registrarsi, senza fornire alcuna informazione personale (che è unica e può essere utilizzata per autenticare quell'utente in futuro), rende la tua applicazione vulnerabile a tale attacco di spam.

    
risposta data 04.12.2014 - 02:55
fonte