Rischi e strategie per implementare l'archiviazione anonima dei token di Google Cloud Messaging?

Question

Rischi e strategie per implementare l'archiviazione anonima dei token di Google Cloud Messaging?

#1 da (1 voti)

1

Sto scrivendo un'app mobile che aggrega i dati meteo e genera una notifica push quando vengono soddisfatti determinati criteri. L'utente ha la possibilità di modificare alcune delle variabili (ad esempio se la temperatura corrente supera X gradi) che è memorizzata sia sul dispositivo che sul mio server.

Quando la mia app si apre, richiede il token GCM (o APN) e le variabili definite dall'utente e le invia al mio server tramite POST. L'endpoint sarebbe simile a questo (se fosse un GET):

https://api.example.com/registerPush.php?key=gcm_key_here&maxtemp=80&type=android

(ovviamente type sarebbe apple se si trattasse di un dispositivo iOS)

Sul lato server, registerPush.php prende le variabili e le memorizza (tramite istruzioni preparate ) in un database MySQL. Il richiedente ha diritto a 1 registrazione per 10 secondi (determinata tramite sessioni PHP) e, se superano tale limite, viene bloccata per 2 minuti, per evitare che un utente tenti di inviare spam al database con voci false.

Ogni ora, un processo cron viene eseguito e scorre tra tutti gli elementi. Se la temperatura supera maxtemp , il token viene aggiunto a un array e inviato in blocco a tali utenti tramite il metodo push corretto (ad esempio GCM o APN).

Mi piacerebbe mantenere questo sistema "anonimo" (ovvero, non è necessario che un utente si iscriva), perché creare un account semplicemente per memorizzare le notifiche push è un po 'eccessivo per la natura semplicistica della mia app e le cose ad esempio "Accedi con Facebook" sono gli stessi, perché perché un utente dovrebbe accedere con Facebook, solo per ricevere le notifiche push?

Quindi la mia domanda è, a meno di limitare i tentativi di registrazione tramite $_SESSION s, e forse di memorizzare l'ultima volta che il token è stato inviato al server (e cancellare vecchi token dopo X molte unità di tempo), cosa posso fare per rendere questo sistema più sicuro, a corto di chiedere alle persone di creare un account (per una semplice app meteo)?

password-management registration

posta DrFrankly 03.07.2016 - 14:37

fonte

1 risposta

Leggi altre domande sui tag password-management registration

Nomi di tabelle strani nel database SQLite RCE in uno script PHP che non ha permessi di scrittura

score 1 · Answer 1

Suggerirei di utilizzare String m_androidId = Secure.getString(getContentResolver(), Secure.ANDROID_ID);

Questo ti darà un ID univoco, che non richiede permessi, che cambia solo durante il reset di fabbrica, e può essere usato per tracciare così nessuno spam il database. Suggerirei anche l'hashing con una chiave specifica dell'app.

Tuttavia, è ancora necessario avere una limitazione per impedire a qualcuno di creare voci dannose. Una buona idea potrebbe richiedere la risoluzione di un captcha per inviare una "nuova" stringa ANDROID_ID che non esiste nel database. Questo può essere risolto con una WebView e utilizzando Google Recaptcha, al primo avvio dell'app, combinato con la limitazione basata su IP.

Ricorda che molti clienti NAT di molti operatori cellulari dietro un IP, quindi custodisci attentamente i registri e se vedi che l'app è popolare e preparati ad aumentare i limiti di throttle, la tua app inizierà ad essere più popolare.

Questo potrebbe essere implementato automaticamente avendo una IA, che confronterà il tasso medio di richiesta per tutti gli IP ad una determinata velocità, e bloccherà solo se la velocità è considerata più alta di questa. Il tasso di richiesta medio è in altre parole, il tasso di richiesta che è la media del tasso di richiesta di tutti gli IP, ma con "low-balls" e "high-balls" rimossi.