Come salvaguardare un'API REST COTS con server on-premise solo per app client approvate?

3

Obiettivo: impedire che le app "clone" non autorizzate utilizzino le soluzioni basate su API REST in cui i clienti gestiscono i propri server e servizi invece del fornitore (database, risorsa e identità). In altre parole: server locali invece di una soluzione basata su cloud.

La mia azienda vuole essere in grado di autorizzare solo alcune terze parti a creare app che possano utilizzare le nostre API, ma non solo chiunque, oltre alle nostre app. Quindi probabilmente avremo qualche processo in cui terze parti ci invieranno le loro app per firmare e aggiungere a una sorta di 'white-list' (qualunque forma finisca col prendere .. da qui la domanda.)

(Perché no cloud? Alcuni paesi e settori sono soggetti a normative più severe laddove i server cloud o off-site non sono un'opzione per alcune classi di dati operativi sensibili. Se questo non è un buon motivo, ti preghiamo di considerare questo un esperimento mentale).

Questa domanda è una variazione su questa domanda quasi identica , ma con il vincolo aggiuntivo che il fornitore di software non possiede o gestisce i server.

Non ho affiliazione con CodeBlue, i creatori di Approov, ma hanno pubblicato una spiegazione decente del processo tipico per proteggere le API REST sia per le app Web sia per le app mobili. Ecco un collegamento alla parte 2 di 3 che copre alcuni dei punti critici come il server di mediazione e il processo di attestazione per autorizzare il cliente e le tecniche per mantenere segreti condivisi dai client pubblici (ad es .: app mobili).

link

La soluzione descritta nell'articolo precedente di CodeBlue suona dandy per un ambiente basato su cloud o controllato da un fornitore. Tuttavia, ho faticato a trovare un modo per proteggere le app clone quando il cliente ha accesso fisico non solo ai client, ma ai server. Probabilmente la sola configurazione potrebbe abilitare app non autorizzate e, se ciò non dovesse funzionare, l'app stessa potrebbe essere modificata.

Ovviamente c'è una rete di sicurezza legale qui (accordo di licenza, termini di servizio), ma c'è qualcosa che possa essere fatto in termini di codice per indurirlo, se non impedirlo a titolo definitivo?

Sono a conoscenza - e perseguendo - varie tecniche per offuscare le soluzioni (come la diffusione dei segreti in giro e la protezione contro il reverse engineering) e per l'attestato dei clienti, ma in tutti i miei modelli finora esiste la possibilità che un cliente malintenzionato (o agente) può ingannare l'API REST facendogli credere che le richieste siano fatte da un cliente autorizzato. So che mi trovo in una specie di corsa agli armamenti qui - quindi mi sto rivolgendo alla comunità per avere dei pensieri su questo perché tutti i metodi che ho esaminato nell'ultima settimana si basano sul fatto che il venditore possiede il server.

    
posta nothingisnecessary 17.09.2018 - 16:28
fonte

2 risposte

2

Sembra che tu abbia un requisito abbastanza specifico.

Tecnicamente non è possibile, ma le persone implementano comunque le soluzioni. Come hai davvero bisogno di renderlo più difficile, non impossibile.

Nel tuo caso renderebbe obsoleta l'API e pubblicheremo le librerie client agli sviluppatori autorizzati con id incorporati. Forse potresti semplicemente crittografare i dati con un segreto condiviso. Oppure usa una serializzazione binaria personalizzata.

In questo modo rendi difficile creare il tuo cliente e riesci a capire chi è trapelato se trovi i client in app non autorizzate.

Il rilascio di aggiornamenti frequenti sui server che modificano l'API appesantirà ulteriormente gli sviluppatori di app non autorizzati.

Naturalmente i tuoi clienti potrebbero scegliere di non installare gli aggiornamenti. Ma alla fine vorranno le funzionalità che vengono con loro.

    
risposta data 18.09.2018 - 19:18
fonte
2

La mia comprensione è che si dispone di una soluzione distribuita che la vostra organizzazione ritiene sicura perché è un'API chiusa e un'app chiusa. Quindi, il mio primo pensiero è di sottolineare che non hai ancora modo di monitorare le app che stanno accedendo alla tua API - non esiste una API privata. Normalmente è banale eseguire il reverse engineering dell'API dall'ascolto del traffico o dalla retroingegnerizzazione dell'app. Poiché il cliente ha sia il lato server che l'app devono già avere accesso a tutto il codice di cui hanno bisogno per raggiungere questo obiettivo. Chiavi API, offuscamento del codice, connessioni bloccate: queste sono normalmente abbastanza facili da aggirare per i professionisti esperti. (Come menzionato regolarmente sui blog Approov di riferimento.)

Detto questo, credo che il tuo caso d'uso possa essere supportato dal normale flusso di Approov ma con chiavi asimmetriche per firmare i JWT usati per trasmettere fiducia tra il servizio cloud Approov e il tuo back-end. L'utilizzo di una chiave asimmetrica consente al back-end di verificare la firma del token senza l'accesso alla chiave privata utilizzata per firmare i token. In questo modo il back-end risponderà solo alle richieste delle app registrate. Naturalmente, questa soluzione non impedirà ai tuoi clienti di clonare completamente il tuo servizio di back-end. come suggerisci, ma come ho detto, hai quel problema con la tua soluzione esistente. (Puoi contattare Approov per vedere come possono supportare questo flusso.)

Dichiarazione di non responsabilità: lavoro a Approov

    
risposta data 21.09.2018 - 11:15
fonte

Leggi altre domande sui tag