App per iPhone sicura ↔ comunicazione server


14

Quale sarebbe l'approccio migliore per raggiungere la comunicazione privata tra la mia app iOS e il suo componente server? Avere una singola "chiave segreta" immutabile è sufficiente nella sorgente dell'app o devo in qualche modo impostare dinamicamente tali generazioni di chiavi "handshake"?

Il server da solo non ha accesso a dati sensibili, quindi anche se l'utente raggiunge alcuni endpoint privati, non li porterà da nessuna parte, ma voglio solo che siano nascosti al pubblico. Fondamentalmente, voglio ignorare tutte le richieste che colpiscono percorsi particolari, a meno che non provengano dalla mia app iOS.

Il componente server viene eseguito su RoR, se questo è importante.

Risposte:


8

Non è possibile rifiutare efficacemente le connessioni se non si fornisce a ogni cliente una chiave privata che è possibile revocare individualmente. Ma questo è probabilmente eccessivo. Non hai bisogno di una soluzione a prova di proiettile se la maggior parte delle persone non si preoccupa di sparare un proiettile.

È una domanda di sicurezza, quindi descriviamo un modello di minaccia e strategie di mitigazione.

Supponiamo che tu abbia un URL che colpisce che può comportare un costo notevole per te (ad es. Costo di elaborazione) e che vuoi proteggerlo sia da un semplice attacco DoS che da app di copione.

Usa SSL per nascondere la connessione dall'analisi facile. Utilizzare un numero di porta non ovvio, una sequenza di reindirizzamento, uno scambio di cookie per complicare leggermente la connessione prima di eseguire la parte costosa della richiesta. Usa del codice segreto inserito nella tua app per far sapere al server che deve accettare la connessione.

Ora qualcuno non può imparare l'URL costoso da colpire semplicemente eseguendo uno sniffer di pacchetti o guardando stringhe simili a URL nel tuo codice. Un potenziale attaccante deve decompilare la tua app.

Non puoi davvero proteggere il tuo codice dall'essere decompilato e / o eseguito con un debugger. L'attaccante alla fine apprende la chiave segreta e la sequenza di connessione.

Ti accorgi che inizi a ricevere richieste di rouge sul tuo costoso URL: in una forma di attacco o in una forma di app copycat che deve accedere al tuo servizio per essere eseguito, o forse un codice di exploit viene pubblicato pubblicamente. Tuttavia, non è possibile distinguere una richiesta non autorizzata da una richiesta legittima.

Crea un aggiornamento secondario gratuito per la tua app, con una chiave segreta diversa. Dovrebbe colpire un altro URL costoso che fornisce gli stessi dati dell'URL costoso compromesso. Per qualche tempo, rendere entrambi gli URL accessibili.

Guarda la tua base di utenti passare alla versione aggiornata. Limita l'URL costoso compromesso e infine 404. Hai appena mitigato una violazione della sicurezza, si spera senza perdere troppo. Torna al punto di partenza.

Disclaimer: non sono un esperto di sicurezza.


Se l'utente ha l'app, può scoprire URL costosi anche se su SSL (il client ha il pieno controllo su certificati, ecc.). Questo rende il resto dell'argomento discutibile per non menzionare che questo è il classico esempio contro la sicurezza attraverso l'oscurità.
aleemb

@aleemb: Sicuramente, non è possibile mantenere l'URL costoso completamente segreto. Un determinato attaccante lo scoprirà. Il punto è rendere questa scoperta anche costosa, in modo tale che uno "script kiddie" avrebbe un tempo difficile (e) e quindi meno incentivi per scavare e sfruttare, e rendere possibile la mitigazione. Se il costo della mitigazione è ragionevolmente basso e il costo della scoperta per l'attaccante è elevato rispetto a qualsiasi guadagno che l'attaccante può ottenere dall'uso dell'URL costoso, l'attacco diventa inutile. Questo, di nuovo, non è una sicurezza rigorosa .
9000,

5

Hai un problema classico che davvero non può essere risolto.

Per garantire una semplice privacy (vale a dire assicurando che i tuoi dati non possano essere ficcati o alterati in transito) puoi fare tutto su SSL e dare al tuo server un certificato emesso correttamente da una CA riconosciuta da iPhone.

Per l'autorizzazione, tuttavia, non esiste una buona soluzione che garantisca al 100% che nessun altro oltre alla tua app possa accedere all'API. La soluzione proposta sarebbe lavorare, ad eccezione di:

  • chiunque abbia scaricato la tua app ha necessariamente in suo possesso la chiave privata
  • se in qualche modo riescono a decomprimere la tua app e decompilarla, avranno la chiave privata in testo normale
  • una volta che hanno la chiave privata in testo normale, possono usarla per firmare le proprie richieste dannose.

Non c'è modo di aggirare questo. Non vuol dire che non potresti adottare questo approccio, ma capire che non è infallibile. È proprio questo problema che rende DRM completamente inefficace .


0

Ecco a cosa servono TLS e SSL . Entrambi possono creare una connessione sicura senza la necessità di una chiave segreta fissa. Leggi la sezione Descrizione sulla pagina collegata per sapere come fanno.

Un modo efficace per ottenere il vantaggio di TLS / SSL senza dover fare molto (qualsiasi) lavoro consiste nel far implementare al server un servizio Web a cui il client accede utilizzando il protocollo HTTPS. HTTPS è solo HTTP su una connessione sicura e il sistema di caricamento URL in iOS lo implementa per te.


Mentre HTTPS nasconde la comunicazione da intercettazioni, non impedisce ai client casuali di connettersi a un endpoint, a meno che il server non richieda un certificato client. Questo potrebbe essere "inserito nell'applicazione" e richiedere alcune conoscenze da estrarre.
9000,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.