2012-03-22 10 views
17

Stiamo costruendo un'app mobile e vogliamo implementare un qualche tipo di autenticazione per assicurarci che l'API sia accessibile solo dalla nostra app. Gli utenti dell'app sono anonimi, senza accessi, anche se li identifico tramite l'id del dispositivo per mantenere le impostazioni e così via.Come assicurarsi che le richieste API provengano dalla nostra app mobile (ios/android)?

L'approccio più semplice sembra generare una chiave Guid/API che invio con ogni richiesta su SSL.

Ciò che mi preoccupa è la possibilità che una persona malintenzionata con molto tempo libero possa scaricare l'app, decompilarla per ottenere la chiave API e le richieste JSON e quindi eliminare il mio database nel modo migliore possibile.

SSL, una chiave API, un ID dispositivo e un'API con chiamate come vincolate-come-possibili sono sufficienti? Dovrei seguire un approccio diverso? Le mie paure sono fondate o infondate?

risposta

18

NON incorporare una singola chiave API nell'app. Le tue preoccupazioni sono valide per quanto riguarda l'effetto degli utenti malintenzionati. Inoltre, hai una grave vulnerabilità nella tua attuale configurazione in cui potresti far sì che un utente API malintenzionato modifichi le preferenze di altri utenti fornendo UDID falsi.

Invece, creare un servizio di "registrazione" che viene richiamato all'avvio dell'app per la prima volta sul dispositivo che genera e restituisce un GUID basato sull'UDID. Archiviare il GUID nelle preferenze dell'utente locale del dispositivo e sul server. Tieni traccia del GUID e confrontalo con l'UDID su ogni richiesta sul tuo server.

Assicurarsi che tutto ciò avvenga su SSL.

Con questo approccio non è presente alcuna chiave API master incorporata da abusare. Inoltre, è possibile inserire nella lista nera utenti abusivi contrassegnando le combinazioni GUID/UDID e si può anche eliminare il problema esistente di potenziale mascheramento dei dispositivi registrati esistenti. Tuttavia, non è possibile impedire la registrazione dannosa di dispositivi che non sono già registrati con il servizio. Ciò rappresenterà sempre un potenziale rischio di utilizzo di un id del dispositivo come identificativo dell'utente.

Esistono meccanismi di autenticazione persino migliori e più consolidati che adottano un approccio migliore, vale a dire. OAuth, JSessionIDs, ecc. Che dovresti dare un'occhiata.

Inoltre, in futuro non si dovrebbe utilizzare l'UDID per identificare i propri utenti poiché l'accesso ad esso è stato deprecato. È possibile simulare l'UDID per i propri scopi creando un GUID del dispositivo personalizzato sul dispositivo al momento dell'installazione dell'applicazione e salvandolo nelle preferenze dell'utente locale.

+0

Non capisco come questo rende tutto più sicuro. Il punto di vulnerabilità è diverso nel tuo caso: il servizio di registrazione. Posso attaccare questo e ho anche pieno accesso. Penso che per Android almeno è forse possibile fare qualcosa di simile: http://android-developers.blogspot.de/2013/01/verifying-back-end-calls-from-android.html – therealmarv

+0

Come attaccheresti il servizio di registrazione per ottenere l'accesso completo? –

Problemi correlati