google cloud messaging security

Question

La società crea un progetto e riceve un ID mittente. La società crea un'app, cuoce l'ID del mittente e posiziona l'app nel negozio.

L'attaccante esegue il reverse engineering della app ed estrae sia l'ID del mittente che l'interfaccia del server utilizzati per ricevere gli ID di registrazione GCM.

L'attaccante crea la propria app, cuoce l'ID del mittente della società e l'interfaccia di registrazione del server, inserisce l'app nel negozio. L'app di attacco impersona fondamentalmente l'app reale dell'Azienda per quanto riguarda GCM: registra per ricevere messaggi dall'ID mittente della Società e quindi invia l'ID di registrazione GCM ai server della Società proprio come fa l'app "reale".

Ora l'azienda desidera trasmettere alcune informazioni a tutte le istanze della sua app. Forse è un promemoria di un aggiornamento disponibile. C'è un modo per differenziare la "attack attack" (che si è registrata esattamente come quella reale) dalle versioni "reali" dell'app della Società?

Answer 1

Lo stesso problema poteva anche esistere con C2DM, che è possibile annusare l'indirizzo di posta elettronica del mittente, invece dell'ID di progetto per GCM.

C2DM o GCM, non deve mai essere utilizzato per inviare informazioni utente sensibili (ad esempio nome account, informazioni private, ecc.), È principalmente utile per la notifica, che l'app reale può utilizzare per eseguire ulteriori azioni.

Non riesco a vedere quanto può essere utile una notifica a un'app "falso/hack", cosa faranno con la notifica "Hai un nuovo messaggio"?

Answer 2

beh, questo potrebbe funzionare anche in una versione di debug dell'app degli hacker, ma non può inserire la sua app nello store. parte dell'identificazione GCM è l'ID app che deve essere univoco nel negozio.

Answer 3

Penso che dal tuo scenario non sia possibile per l'utente malintenzionato inviare un messaggio all'utente anche se ha l'ID di registrazione. Il server aziendale che invia i messaggi di cui hanno bisogno per autenticarsi (OAuth2) li tiene in considerazione prima tramite Google. Pertanto, solo se l'utente malintenzionato conosce la password della parte mittente e l'ID di registrazione di quanto non possa inviare l'utente. Ma la password della parte mittente non viene mai inviata al lato client.

Answer 4

L'ID di registrazione GCM è richiesto da Google, richiesto dall'app e inviato al server. Quando qualcuno con un'app diversa (ma lo stesso ID mittente) crea un Regid, deve comunque essere impegnato sul server e devi prima inviare esplicitamente un messaggio a quel specifico regid.

Un'installazione di app, legittima o meno, non può mai ricevere messaggi per cui non è autorizzata. (A condizione che tu dichiari e utilizzi l'autorizzazione C2D_MESSAGE)

Answer 5

In realtà, google ti consente di registrare una chiave server per GCM, che ti consente di utilizzare IP del server White-List ... Quindi dovresti aggiungere l'IP del tuo server e saresti al sicuro , dal momento che solo il tuo server può inviare messaggi con quella chiave.

Answer 6

GCM è sicuro in questo caso.
Non è nemmeno possibile utilizzare l'ID mittente nell'app originale prima di registrare l'app in GoogleApiConsole. Ciò significa che punti l'impronta digitale della chiave privata in GoogleApiConsole. È abbastanza.

Answer 7

Suggerirei di avere il proprio "server temporaneo" che utilizza la chiave API (ID mittente a cui ci si riferiva). Invece di inserirlo nell'app stessa.