it-swarm.dev

Protezione di un'API per l'accesso mobile

Ho creato un'API REST/JSON di Nizza che viene utilizzata da altre aziende (i nostri clienti) come servizio B2B. Ognuno dei nostri clienti ha una coppia nome utente/password e facciamo anche HTTPS e convalidiamo l'IP di origine delle richieste al servizio. L'utilizzo del servizio costa denaro e il cliente viene fatturato mensilmente per l'utilizzo del servizio.

Ora, alcuni client stanno creando applicazioni mobili che distribuiscono ai loro utenti (B2C - utenti finali). Non tutti questi utenti finali del nostro servizio hanno server e desiderano utilizzare il servizio direttamente dallo smartphone (che tecnicamente non è un grosso problema essendo JSON/REST).

Il problema è che non sono sicuro di come proteggere il servizio dalle frodi. Cosa impedirà a uno sviluppatore di terze parti di disassemblare un'applicazione mobile del client e copiare il proprio nome utente/password/qualunque credenziale di sicurezza e utilizzarlo nella sua applicazione? Ciò gli consentirebbe di consumare il servizio e addebitare l'utilizzo a uno dei nostri clienti legittimi!

Sono abbastanza sicuro che non esiste una soluzione crittografica perfetta per questo problema, a meno che gli utenti finali non siano autorizzati ad autenticarsi su un server. Ma questo non è sempre il caso.

Come ultima risorsa credo di poter distribuire una libreria offuscata per Android/IPhone, che almeno darebbe l'illusione della sicurezza ...

EDIT (chiarimento):

Vorrei provare a semplificare lo scenario.

  1. Ho un server Web non hackerabile che serve un'API JSON REST.
  2. I client mobili accedono direttamente alla mia API. I loro IP non possono essere convalidati. Stanno eseguendo un sistema operativo standard (Android/IOS).
  3. Non ci sono altri server coinvolti.
  4. Non riesco ad accedere all'IMEI del telefono (è considerato privato), né mi aiuterebbe perché non conosco gli utenti finali.
  5. Esistono diverse applicazioni mobili legali, sviluppate da diverse società che accedono alla nostra API.
  6. L'attuale sicurezza (nome utente/password) è facilmente hackerabile da parte di una canaglia. Detta società canaglia disassembla un'applicazione mobile legittima e copia il nome utente/la password nella loro applicazione illegale. Distribuiscono questa applicazione e i profitti (l'utilizzo dell'API viene addebitato alla società da cui hanno rubato le credenziali).

Questo può essere fermato?

16
Tal Weiss

La tua domanda è "Questo può essere fermato?", Ma ho la sensazione che qualcosa di significativo nel sistema non possa/non possa essere realmente cambiato.

Se ho capito bene, mi stai chiedendo (semplificato):

Ho molti clienti che condividono lo stesso nome utente e password. Posso smettere di abuso?

La risposta è no. È necessario decidere se è possibile ignorare il problema o implementare soluzioni corrette.

Se vuoi davvero farlo correttamente, cerca di implementare qualcosa come OAuth, in modo da poter distribuire correttamente token di autenticazione separati per gli utenti finali, collegarli ai tuoi clienti per la fatturazione, revocare l'accesso, ecc.

-

Il minimo che dovresti fare è consentire ai tuoi clienti (le aziende) di optare per uno schema di autenticazione migliore. Quindi, ad esempio, crei un'API per richiedere (e revocare) token di accesso separati per i loro utenti finali.

  • Azienda A richiede token dai loro server (questo viene avviato dalla loro app dicendo loro "dammi un token")
  • Restituisci il token N, registra a quale compagnia è collegata
  • Se la società A-s si connette al tuo servizio, invia il token N e non nome utente/password
  • La società A può dire al tuo servizio "revoca il token N" e altre richieste con quel token non saranno servite dal tuo servizio. Tuttavia, se un token viene revocato, non renderà inutilizzabili tutte le app client.

Se un'azienda non vuole farlo, può comunque continuare a connettersi utilizzando il proprio nome utente/password, ma sarebbe completamente responsabile di tutto l'utilizzo risultante.

Il punto è che non puoi davvero rendere i tuoi clienti responsabili delle perdite di credenziali (cosa che è impossibile fare in uno scenario di app mobili) se non hanno altro modo di utilizzare il servizio.

7
Joel L

Quindi spero di averlo corretto. Desideri un modo sicuro per confermare l'identità di un client utilizzando una chiave API valida? Penso che l'archiviazione sicura della chiave API sia in gran parte responsabile della società che ha sviluppato l'applicazione e non della tua azienda.

Dovrai crittografare e offuscare la chiave per proteggerla dall'hacker occasionale, ma non credo che sarai mai in grado di prevenire un determinato hacker. Potresti fare un po 'di pirateria informatica per rendere più difficile il debug del binario, il che potrebbe ridurre le possibilità che la tua app fluttui su Internet. Tuttavia, questa non è una sicurezza assoluta e, a meno che la tua azienda non stia sviluppando le applicazioni internamente, come puoi applicare tali misure?

Quindi, come risposta al tuo scenario, no, non penso che possa essere effettivamente interrotto senza pregiudicare l'esperienza degli utenti. Puoi educare le aziende usando la tua API, mettere insieme un piccolo manuale per loro e assicurarti che sia chiaro che è loro responsabilità di mantenere loro chiave API.

Da parte tua, potresti anche implementare alcune funzionalità di mitigazione. Per esempio:

  1. Consentire alle aziende di definire i propri limiti rigidi. Supponiamo che la società A sappia che il mese scorso hanno avuto N download di app e quindi vogliono limitare il loro accesso all'API alle richieste X al giorno o all'ora.
  2. Monitorare eventuali picchi di richieste per azienda per periodo di tempo.
  3. Definire un passaggio di procedure che potrebbero verificarsi su potenziali attività fraudolente.
  4. Re-key, re-key e re-key.

L'obiettivo in caso di fallimento (succede al meglio) è minimizzare il danno.

In bocca al lupo.

6
Kurt

Hai ragione a essere scettico sul fatto che i tuoi clienti incorporino il loro nome utente/password in un'app mobile che distribuiscono a tutti i loro utenti. Come hai identificato correttamente, per alcuni utenti malintenzionati sarebbe facile smontare quell'app mobile, estrarre il nome utente/la password dall'app mobile e utilizzarla nella propria app. Sfortunatamente, il tuo cliente è quello che decide se farlo, ma il costo è a carico tuo. Quindi, questa è un'esternalità e avrai bisogno di un modo per allineare meglio costi, rischi e incentivi. Ho alcuni suggerimenti qui sotto su come farlo.

In generale, vedo due soluzioni plausibili a questo:

  • Trasferimento del rischio. Per ogni cliente, imporre un limite al numero di richieste che accetterete da quel cliente. Informare i clienti che è loro responsabilità mantenere sicuri il loro nome utente/password, che tutte le richieste che arrivano utilizzando questo nome utente/password verranno conteggiate rispetto al loro limite e che se arrivano troppe richieste, il loro account potrebbe essere disabilitato. Spiega loro che se incorporano il loro nome utente/password in un'app mobile, c'è il rischio che qualcuno di malvagio possa rubare il nome utente/password e utilizzarlo per fare molte richieste, facendo sì che il loro account venga disabilitato e la loro app mobile smetta di funzionare . Lascia che decidano se vogliono correre il rischio o meno.

  • Requisiti contrattuali. Spiega ai tuoi clienti che è proibito condividere il loro nome utente/password con altri, e non è consentito per loro incorporare il loro nome utente/password in app che possono essere scaricate da altri. Informali che se rilevi violazioni di questa politica, il loro account potrebbe essere disabilitato e potrebbero essere fatturati per eventuali costi che ciò comporta per i tuoi server.

    Se i tuoi clienti desiderano creare un'app mobile, comunica ai tuoi clienti che, invece di incorporare il proprio nome utente/password nell'app mobile, devono eseguire il proxy di tali richieste sul proprio server. In altre parole, il client dovrebbe configurare un server che conosca il nome utente/la password del client, ma questo nome utente/password non devono essere incorporati nell'app mobile. L'app mobile del client deve autenticarsi sul server del client, inviare una richiesta al server, quindi il server deve inoltrare la richiesta all'utente e inoltrare la risposta all'app mobile. Il loro server dovrebbe autenticare l'utente finale (ad esempio, richiedere a ciascun utente finale dell'app mobile di creare un account sul proprio server, con il proprio nome utente/password). Il loro server dovrebbe imporre limiti di larghezza di banda in base all'utente e disabilitare l'account di qualsiasi utente finale che superi tali limiti.

Puoi anche consentire ai clienti di scegliere tra queste due opzioni: ad esempio, tra un account a larghezza di banda limitata (con trasferimento del rischio) o un account a larghezza di banda illimitata (con l'obbligo di non incorporare il nome utente/la password in app accessibili ad altri ).

Spero che abbia senso. Questo può essere un po 'confuso, perché ci sono tre parti - tu, il tuo cliente e l'utente finale del vostro cliente - ognuno con i propri interessi e preoccupazioni. Spero di aver adeguatamente distinto tutti e tre.

3
D.W.

La protezione dei dati nella trasmissione con SSL ha già coperto l'attacco man-in-middle. Le password codificate nel codice sorgente non sono comunque pratiche sicure. Non dovresti preoccuparti dell'indirizzo IP degli utenti o dell'IMEI. Non parliamo di tracciamento e proviamo a risolvere le cose in primo luogo.

Come hai detto, stai usando REST. Spero che poche cose ti possano aiutare.

  1. Autenticare gli utenti dal lato server. Mantenere una gestione rigorosa della sessione in modo che non possa essere falsificata. Dai un'occhiata a OWASP per questo.
  2. Fai un test fuzz per la tua API. ReST è noto per alcune vulnerabilità. Esplorali su Internet e scopri la maggior parte dei bug noti in ReST. Patch quei problemi per la tua API.
  3. La tua cosa SSL è buona che sta proteggendo i tuoi dati nel mezzo.

Non preoccuparti per il tuo codice sorgente. Può essere strappato comunque, ma va bene. Le tue funzioni principali devono essere in esecuzione sul server e passare le risposte ai client. Tieni tutte le cose buone sul lato server.

1
mojo

Uno dei problemi che penso che dovrai affrontare sul fronte mobile è la convalida dell'indirizzo IP. In genere, gli indirizzi IP mobili assegnati da Telco vengono compensati. L'IP compensato renderà inutile il meccanismo di validazione IP adottato nel lato server.

Per implementare la soluzione su Android e Iphone; penso che l'approccio dovrebbe essere:

  1. Chiedere che l'autenticazione del server client in modalità SSL sia estesa anche alla convalida del certificato client. Voglio dire, sia il client che il server utilizzano entrambi i certificati per stabilire una sessione SSL sicura.
  2. Fornire il PFX/P12 contenente il certificato client (mobile) in modo tale da richiedere un PIN e una combinazione di numeri IMEI e IMSI. In questo modo sarà difficile per un utente malintenzionato ripudiare il stessa sessione.
  3. Far implementare alcune IA sul server che rilevi due o più sessioni simultanee avviate utilizzando lo stesso certificato client che ti farà sapere che si sono verificati alcuni compromessi e che il server può immediatamente inserire nella blacklist o revocare il certificato per un ulteriore utilizzo.

Credo che stessimo discutendo per l'ambiente mobile; oltre alla validazione IP, i rischi sono presenti anche in ambiente PC. In futuro è possibile adottare o migrare all'implementazione basata su firma e basata su certificato client in ambiente PC, anche se si verificano problemi di fatturazione errati sollevati dai clienti.

1
Mohit Sethi

La frode è varia e non può essere risolta solo da un'implementazione tecnica, ma se hai implementato la convalida e il blocco IP intensificati, non c'è nulla di cui preoccuparsi. Inoltre, non devi fornire le credenziali effettive ai tuoi clienti (B2B). Lasciami spiegare perché e come.

Dalla mia comprensione di ciò che hai scritto, i concetti e le implementazioni di sicurezza da base a media sono già stati applicati per quanto riguarda il lato B2B (YOURCOMPANY - YOURCLIENT). Quello è buono. Convalida IP, SSL/TLS, Utente/Pass ecc. Ora, ti preoccupi che le credenziali API utilizzate dai tuoi clienti per consegnare applicazioni mobili agli utenti finali possano essere imperfette in modo che un utente finale di terze parti trarrebbe vantaggio queste credenziali se l'app mobile del tuo client è stata sfruttata in qualche modo.

Fondamentalmente si riduce a una serie di livelli di sicurezza. La domanda è: come la tua azienda ha progettato e implementato questi livelli?

  1. Il SERVER API JSON/REST deve contenere le credenziali effettive. Se si sta fornendo un servizio e si richiede una connessione a un provider/operatore di rete, è possibile trovare anche queste credenziali qui. Sai cosa intendo.

  2. Non concedere a YOURCLIENT l'accesso diretto al SERVER API JSON/REST. Invece, è necessario un host Jump che fungerà da host per l'ambiente attendibile, il server API da cui risiede l'applicazione JSON/REST dovrebbe autenticarsi SOLO con questo server utilizzando la convalida/il blocco dell'indirizzo IP. Autenticazione da server a server tramite IP o coppie di chiavi pubbliche/private. È tua discrezione cosa usare.

Questo server dovrebbe fungere anche da servizio Web contenente un set di nome utente/password che si associa quindi a un file di configurazione e passa la richiesta al SERVER API JSON/REST. Ora, YOURCLIENTS dovrebbe avere accesso a questo server anche sulla base della convalida/blocco IP e protetto mediante HTTPS. Il concetto è che qui non è possibile trovare credenziali utente/pass effettive ad eccezione della chiave/segreto associato all'API SERVER.

  1. YOURCLIENT può avere un'implementazione della sicurezza dalla propria parte agli utenti finali. Può essere in una forma di coppia di chiavi pubblica/privata PKI per sviluppatori o un 2FA per utenti ordinari. YOURCLIENT dovrebbe implementare questi passaggi, non la tua azienda.

Ora, ad esempio, uno sviluppatore di terze parti (utente finale) ha sfruttato un difetto in un'applicazione mobile creata da uno dei TUOI CLIENTI e ha ottenuto le loro credenziali:

  1. Inutili. Per quanto riguarda il fatto che, al fine di utilizzare le credenziali, il tuo IP verrà convalidato.
  2. Non valido. Per quanto riguarda il fatto che è necessario essere autenticati tramite una coppia di chiavi pubblica/privata.
  3. La tecnica di escalation dei privilegi richiederà che sfrutti il ​​server effettivo per essere attendibile.
  4. Lo sfruttamento del server effettivo richiede tecniche elaborate che rallentano la motivazione di un attaccante.
  5. Non esiste un attacco riuscito la cui motivazione sia terminata.

L'offuscamento è buono e rallenta un attacco, ma è la minima forma di sicurezza. Dovresti affidarti meglio a crypto che utilizza le chiavi.

Ricorda, non esiste una soluzione di sicurezza assoluta a parte il tuo continuo sforzo per combattere le frodi da una prospettiva di sicurezza tecnica e operativa.

1
John Santos