OAuth2 e SSL sono sufficienti per proteggere un'API

Question

Sto cercando di capire il modo migliore per proteggere un'API. Consento solo SSL e sto usando OAuth2 per l'autenticazione, ma non mi sembra abbastanza.

La preoccupazione principale che ho è che chiunque può ispezionare le richieste fatte da un client legittimo all'API e rubare OAuth id_cliente. A quel punto sarebbero in grado di costruire qualsiasi richiesta che vogliono impersonare il cliente legittimo.

C'è un modo per impedirlo? Ho visto persone usare un hash HMAC dei parametri usando una chiave segreta nota solo al client e al server ma vedo 2 problemi con quello.

1. È molto difficile (impossibile?) Impedire a un utente malintenzionato di decompilare il client e capire la chiave segreta.
2. Alcuni parametri sembrano strani per creare un hash HMAC. Ad esempio, se un parametro era byte di un file, includi l'intera cosa nel tuo hash HMAC?

Answer 1

È possibile distribuire SSL reciprocamente autenticati tra i client legittimi e l'API. Genera un certificato client SSL autofirmato e memorizzalo nel tuo client. Configura il tuo server per richiedere l'autenticazione lato client e accetta solo i certificati che hai distribuito ai tuoi clienti. Se qualcuno/qualcosa che tenta di connettersi non ha quel certificato client, non sarà in grado di stabilire una sessione SSL e la connessione non verrà effettuata. Supponendo che controlli i client legittimi e i server, non hai bisogno di un certificato emesso dalla CA qui; è sufficiente utilizzare i certificati autofirmati poiché si controlla sia il trust del certificato lato client sia quello lato server.

Ora, si fa notare che è davvero difficile impedire a qualcuno di decodificare il client e recuperare le credenziali (la chiave privata che appartiene al certificato client, in questo caso). E hai ragione. Normalmente, memorizzerai quella chiave (e il certificato) in un keystore di qualcosa (uno KeyStore se stai usando Android) e quel keystore sarà crittografato. Quella crittografia è basata su una password, quindi dovrai (1) memorizzare la password nel tuo client da qualche parte, o (2) chiedere all'utente la password quando avvieranno l'app client. Quello che devi fare dipende dal tuo caso. Se (2) è accettabile, hai protetto le tue credenziali contro il reverse engineering poiché sarà crittografato e la password non verrà memorizzata da nessuna parte (ma l'utente dovrà digitarlo in ogni momento). Se si esegue (1), quindi qualcuno sarà in grado di decodificare il client, ottenere la password, ottenere il keystore, decrittografare la chiave privata e il certificato e creare un altro client che sarà in grado di connettersi al server.

Non c'è niente che puoi fare per impedirlo; puoi rendere più difficile il reverse engineering del codice (offuscamento, ecc.) ma non puoi renderlo impossibile.È necessario determinare quale sia il rischio che si sta tentando di mitigare con questi approcci e quanto vale la pena lavorare per attenuarlo.

Answer 2

Stai eseguendo il passaggio di autenticazione OAuth su SSL stesso? Ciò impedisce qualsiasi tipo di spionaggio, ma ciò significa che dovrai stare attento a mantenere aggiornato il certificato del tuo server OAuth. (Nota, il server OAuth può avere un'identità SSL pubblico; è ancora impossibile stringere anche con vagamente ragionevole quantità di sforzo E 'solo la chiave privata che ha bisogno di essere tenuto segreto..)

Detto questo, è devi essere più attento a ciò che stai proteggendo. Perché le persone devono usare il codice cliente? Perché deve essere "segreto"? Più facile darlo via e mettere le intelligenze (inclusa la verifica dell'identità di accesso) sul tuo server. Se qualcuno vuole scrivere il proprio cliente, lasciali. Se qualcuno vuole sventare il proprio account in pubblico in modo sciocco, addebita loro i costi sostenuti per la sua follia ...