2012-01-09 14 views
5

La sezione Security Controls nella panoramica fatturazione in-app istruisce per effettuare una "verifica della firma" in un server remoto, piuttosto che in app (in esecuzione localmente sul dispositivo Android):Perché la verifica della firma sul server remoto è più sicura che sul dispositivo?

Eseguendo la verifica della firma è possibile aiuta a rilevare le risposte che sono state manomesse o che sono state falsificate. È possibile eseguire questo passaggio di verifica della firma nell'applicazione; tuttavia, se l'applicazione si connette a un server remoto sicuro, si consiglia di eseguire per la verifica della firma sul server .

Ma se eseguire la verifica della firma sul server remoto, in attesa di una risposta solo yes/no o true/false, non è questo in realtà più facile da intercettare e modificare da un attaccante?

E se la risposta dal server remoto è ancora un'altra firma, allora come verificare la seconda firma localmente sul dispositivo in modo più sicuro rispetto alla prima firma (Mercato)?

Cosa mi manca?

Aggiornamento: @alf ha osservato giustamente che se il server è anche responsabile per la distribuzione di contenuti acquistati e la verifica della firma viene eseguito sul server, quindi anche se l'attaccante compromette l'applicazione, il server non consegnare il contenuto acquistato tramite fatturazione in-app. Questo è banale e ben compreso.

Quello che ho omesso di menzionare in origine è che sto in realtà di uno scenario in cui il server non eroga alcun contenuto ma verifica solo la firma, in modo che l'applicazione può decidere se sbloccare alcune funzioni . In tal caso, qual è il vantaggio della verifica della firma del server remoto su quella in-app?

+0

Mi chiedo anche se il controllo della firma del server è davvero necessario quando si implementa la fatturazione in-app solo per sbloccare funzionalità. Quali sono stati i tuoi risultati? –

risposta

3

non è in realtà più facile da intercettare e modificare da un utente malintenzionato?

Se si utilizza SSL per comunicare con il server, non possono intercettare e modificare la risposta. SSL verifica anche l'identità del server, quindi sei sicuro di parlare con il tuo server, non con quello del pirata informatico.

Per quanto riguarda il motivo per cui eseguire la verifica della firma sul server, l'idea del commento originale del documento è che se lo si fa sul client, è necessario memorizzare la chiave pubblica all'interno dell'app. L'autore dell'attacco potrebbe presumibilmente scambiare la chiave con la propria e le firme generate dagli aggressori verranno verificate correttamente. Puoi evitarlo eseguendo la verifica sul server. Tuttavia, strumenti di cracking della vita reale come AntiLVL cercano il bytecode che restituisce true/false e lo modifica per restituire sempre true.

+0

E con questo cosiddetto ["trucco intelligente del certificato SSL"] (http://techcrunch.com/2011/11/14/siri-cracked-open-theeticetic-opening-it-up-to-other-devices-or -even-android /) sembra che non ci sia alcun tipo di verifica, nemmeno sul server via SSL ... –

+0

Niente di speciale su questo - è solo lo spoofing del DNS. Questo può essere fatto facilmente in un ambiente di laboratorio controllato, ma non banale su Internet reale. Soprattutto per i siti principali. –

2

Perché si ha il controllo del codice di verifica sul server. Il codice sul dispositivo potrebbe essere stato compromesso.

+3

Ma il codice che controlla 'true/false' sul dispositivo potrebbe anche essere compromesso ... Cosa mi manca? –

2

Se non si esegue la verifica della firma sul server, l'utente malintenzionato non si preoccuperà del proprio dispositivo. Oppure, se lo desidera, può scaricare la tua app, decompilarla e rimuovere la verifica. Cosa farai contro un'app modificata?

+0

Anche se eseguo la verifica della firma sul server, l'utente malintenzionato può decompilare l'app e rimuovere semplicemente la parte che comunica con il server per ottenere il risultato della verifica. Cosa farò contro questo? –

+2

In questo caso, l'autore dell'attacco non otterrà il tuo prezioso contenuto che è responsabilità del server consegnare. Il presupposto è che i server Android Market siano affidabili (ha!), Il tuo server è affidabile, ma non hai il controllo dell'applicazione. – alf

+0

In questo caso hai ragione, ovviamente. Ho dimenticato di menzionare che sto parlando dell'utilizzo della fatturazione in-app per sbloccare funzionalità, non per fornire contenuti. Puoi riferirti a quello scenario? +2 per ora. –

Problemi correlati