Protezione delle richieste di riposo delle app mobili

3

Sto utilizzando il login di Facebook in un'app mobile nativa e sto cercando di capire se il mio approccio è abbastanza sicuro.

Questo è il flusso (tutte le comunicazioni avvengono tramite SSL):

  1. L'utente accede a Facebook tramite l'app mobile.

  2. L'app passa la chiave di accesso a breve termine di Facebook dell'utente al server.

  3. Il server utilizza la chiave e invia una richiesta a Facebook per recuperare i dettagli dell'utente e ottenere la chiave di accesso a lungo termine di Facebook.

  4. Se la richiesta di Facebook ha esito positivo viene creato un utente nel mio DB.

  5. Viene quindi creato un oggetto per quell'utente, che include il suo ID di Facebook, il token di Facebook e la data di creazione. Tale oggetto viene crittografato utilizzando Rijndeal (256 bit) e restituito al client. D'ora in poi tutte le richieste dal client includono quel token. Il token è valido per 48 ore. Quando il token scade, uso ancora una volta la chiave di accesso di Facebook e faccio una richiesta a Facebook. Se la chiave di accesso di Facebook è ancora valida, un nuovo token viene generato e restituito al client.

  6. Quando l'utente vuole i suoi dati, il client invia il token, se la decrittografia del token ha esito positivo uso il suo Facebook Id (che è anche l'ID che uso per l'utente), che fa parte del token, per recupera i suoi dati e li rimanda al client.

Ho due domande -

  1. Il flusso è sicuro?
  2. Quando crittografo il token, dovrei usare diversi IV e sale per ogni token? (La mia ipotesi è che sia necessario, ma vuol dire che dovrei memorizzare IV e Salt nel DB, e in realtà recuperarlo in ogni chiamata effettuata dal cliente - sembra abbastanza espansivo).
posta Udi Idan 28.03.2014 - 16:51
fonte

1 risposta

0

La sicurezza di questo dipende da come esattamente si esegue la crittografia. Se utilizzi la modalità CBC e il controllo dell'integrità, vedo una debolezza che potrebbe consentire a un utente della tua app di impersonare un altro utente:

  1. L'autore dell'attacco ottiene legittimamente un token per il proprio account Facebook. Attendono quindi 48 ore in modo che il token non sia valido. Se presentano questo token sul tuo server, ottengono problemi con un nuovo token. Fondamentalmente, in questa richiesta, conta solo l'ID di Facebook: il token di Facebook è irrilevante.
  2. Se la crittografia non ha il controllo dell'integrità, possono manomettere il proprio token per modificare il proprio ID di Facebook. Se la crittografia utilizza la modalità CBC, allora questo è abbastanza banale. Quando presentano il token alterato, ottengono quindi un token legittimo per l'ID di Facebook dell'altro utente.

È possibile risolvere questo problema utilizzando il controllo dell'integrità e la crittografia. In effetti, potresti effettivamente voler abbandonare la crittografia e utilizzare semplicemente il controllo dell'integrità. Hai SSL per crittografare tutto sul filo comunque.

Un'altra considerazione: in che modo esattamente gli utenti accedono a Facebook? Dovresti utilizzare il pulsante "Accedi con Facebook" ( informazioni iOS ) piuttosto che presentare una pagina Web direttamente nella tua app.

    
risposta data 30.03.2014 - 21:56
fonte

Leggi altre domande sui tag