Come posso impostare il mio server in modo che accetti solo le richieste dalla mia app cliente? (simile ai certificati client SSL)

4

Mi piacerebbe che le mie API del server accettassero solo richieste dalla mia app, per evitare altri client "canaglia" del mio servizio.

Come ho capito, il modo per farlo sarebbe con un "certificato client" che l'app invia e che il server web è configurato per verificare.

Tuttavia, sto ospitando la mia app in Heroku, e credo che non sia possibile farlo, quindi cerco qualcosa che mi permetta di raggiungere questo obiettivo.

Ho pensato che forse avrei potuto avere una coppia di chiavi, in cui il client utilizza una chiave privata per firmare un determinato token concordato (più un salt casuale, in modo che la stringa crittografata sia sempre diversa) e il server utilizzi chiave pubblica per verificare il token (e rifiuta i sali duplicati per impedire la riproduzione). O forse il cliente firma l'intera richiesta con la sua chiave privata, o qualcosa del genere.

L'idea sarebbe che anche se qualcuno riesce a aggirare il nostro blocco SSL (con qualcosa come iOS kill switch, potenzialmente) e ispezionare il nostro traffico e capire come funziona la nostra API, non possono ancora chiamarci a meno che non invertano ingegnere il file binario per estrarre quel certificato / chiave privata. Capisco che è possibile farlo, sto solo provando a sopportare il maggior numero di barriere possibile.

Quali sono i modi migliori per farlo?

Grazie!
Daniel

    
posta Daniel Magliola 17.02.2015 - 14:01
fonte

4 risposte

7

Questo tipo di problema si presta a Sicurezza Cargo-Cult tipo "soluzioni".

Nel mondo reale non esiste alcun meccanismo che possa impedire a un client canaglia di connettersi al tuo servizio. Una VPN è un sistema di sicurezza comprovato che consente ai client fidati di accedere a una rete fidata , ma Internet è intrinsecamente inaffidabile. L'utente malintenzionato avrà accesso a qualsiasi segreto incorporato nella tua app o archiviato nella memoria dell'app, i certificati client TLS si basano su un segreto.

Quando progetti un servizio web non dimentichi mai: " Il client è l'attaccante e non può mai essere considerato attendibile. " Se hai commesso questo errore, devi tornare al tavolo da disegno.

    
risposta data 17.02.2015 - 15:44
fonte
1

Nota

Questa risposta è applicabile solo sotto le ipotesi indicate. Li ho fatti basandomi sulla formulazione esplicita della domanda, che consente esplicitamente di non mitigare un vettore di attacco noto.

La sicurezza è un equilibrio relativo tra il valore della perdita nel caso in cui una risorsa sia compromessa e lo sforzo (incluso il costo, ecc.) che un avversario è disposto a fare per raggiungere tale compromesso. È una prerogativa dell'autore decidere su un equilibrio tale da avere il quadro completo delle parti interessate.

Ipotesi

La minaccia che stai tentando di mitigare è quella di un avversario che può leggere / manomettere le proprie comunicazioni, impersonare il client, ma non eseguire il reverse engineer il contenuto del file binario (a causa di un mancanza di capacità tecnica, o mancanza di volontà).

TL; DR

HMAC(message | nonce, key) insieme al messaggio del cliente / nonce "in chiaro" (su TLS, ma senza ulteriori crittografia).

Risposta dettagliata

La tua domanda è una delle autenticazione , ma sembra che tu stia tentando di risolverla con la crittografia (sì, c'è qualche crossover in determinate circostanze, ma la separazione delle due sarà rendere la risposta più semplice).

Se una chiave segreta (non una chiave privata asimmetrica, solo un numero casuale sufficientemente grande, crittograficamente sicuro) viene archiviata nel file binario (come si stava proponendo con una coppia di chiavi pubblica / privata), quindi non viene rivelato da conoscenza della HMAC / coppia di testi in chiaro.

Il server è anche a conoscenza della chiave, calcola l'HMAC per il messaggio ricevuto e scarta tutte le comunicazioni client non valide. Il nonce viene fornito dal server al client prima di inviare il messaggio ed è univoco. Agisce per proteggere dai replay dei messaggi intercettati.

Caveat

Come notato in precedenza e in altre risposte / commenti, si può ancora ottenere la chiave dal binario. Per coloro che sono interessati c'è una tecnica davvero interessante che calcola l'entropia per tutte le regioni del binario, quindi mappa la posizione lineare in un Curva di Hilbert . Le regioni di codici macchina avranno un'entropia relativamente inferiore rispetto alle regioni "chiave". Chris Domas lo dimostra in uno dei suoi video; forse il suo TED talk anche se non riesco a ricordare (guarda il video TED in entrambi i casi).

    
risposta data 30.04.2015 - 12:27
fonte
0

Puoi andare con qualsiasi meccanismo di tunneling per accettare gli IP particolari sul lato server o semplicemente configurare il firewall per accettare l'elenco di client fidati.

    
risposta data 17.02.2015 - 19:08
fonte
0

Utilizza OAuth2.0 . Non solo autorizza l'utente, ma anche l'applicazione client con proprietà client_id e client_key .

    
risposta data 30.04.2015 - 10:17
fonte

Leggi altre domande sui tag