Protezione di un'API per l'accesso mobile

La tua domanda è "Può essere fermato?", ma ho la sensazione che qualcosa di significativo sul sistema non possa / non sarà realmente cambiato.

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

I have many clients sharing the same username and password. Can I stop misuse?

La risposta è no . Devi decidere se puoi permetterti di ignorare il problema o implementare soluzioni corrette.

Se vuoi davvero farlo correttamente, cerca di implementare qualcosa come OAuth, così puoi 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 l'utilizzo di uno schema di autenticazione migliore. Quindi, ad esempio, crei un'API per loro per richiedere (e revocare) token di accesso separati per i loro utenti finali.

• La compagnia A richiede token dai loro server (questo è iniziato dalla loro app che dice loro "dammi un token")
• Restituisci il token N, registra a quale azienda è collegato
• Se l'app dell'Azienda A si collega al tuo servizio, invia il token N e non il nome utente / password
• La società A può comunicare al tuo servizio "revocare il token N" e ulteriori richieste con quel token non saranno servite dal tuo servizio. Ma, se un token viene revocato, non renderà tutte le app client inutilizzabili.

Se una società non vuole farlo, può comunque continuare a connettersi usando il suo nome utente / password, ma sarebbe completamente responsabile per tutto l'utilizzo risultante.

Il punto è che non si può davvero ritenere i propri clienti responsabili di perdite di credenziali (cosa che è impossibile fare in uno scenario di app per dispositivi mobili) se non hanno altro modo di utilizzare il servizio.

Quindi spero di averlo corretto. Vuoi un modo sicuro per confermare l'identità di un client utilizzando una chiave API valida? Penso che la memorizzazione sicura della chiave API sia in gran parte responsabile dell'azienda 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 hacker determinato. Potresti fare un po 'di hacker per rendere il binario più difficile da eseguire il debug che potrebbe ridurre le possibilità che la tua app fluttuasse 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 efficacemente fermato senza essere dannoso per l'esperienza degli utenti. Puoi educare le aziende utilizzando la tua API - crea un piccolo manuale per loro e assicurati che sia chiaro la loro responsabilità di mantenere la loro sicurezza della chiave api.

Da parte tua, potresti anche implementare alcune funzioni di mitigazione. Ad esempio:

1. Permetti alle aziende di definire i propri limiti rigidi. Supponiamo che l'azienda A sappia che il mese scorso hanno avuto download di app N e quindi vogliono limitare il loro accesso alla tua API alle richieste X al giorno o all'ora.
2. Monitora eventuali picchi di richieste per azienda per periodo.
3. Definire una fase delle procedure che potrebbero verificarsi su potenziali attività fraudolente.
4. Ri-tasto, ri-tasto e ri-tasto.

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

Goodluck.

Hai ragione a essere scettico riguardo ai tuoi clienti che incorporano il loro nome utente / password in un'app mobile che distribuiscono a tutti i loro utenti. Come hai identificato correttamente, per un malintenzionato sarebbe facile disassemblare quell'app mobile, estrarre il nome utente / password dall'app mobile e utilizzarla nella propria app. Sfortunatamente, il tuo cliente è colui che decide se farlo, ma il costo è imposto a te. Quindi, questa è un'esternalità e avrete bisogno di un modo per rendere i costi, i rischi e gli incentivi meglio allineati. Ho alcuni suggerimenti qui sotto su come farlo.

In generale, vedo due soluzioni plausibili a questo:

• Trasferimento del rischio. Per ogni cliente, imponi un limite al numero di richieste che accetti da quel client. Spiega ai clienti che è loro responsabilità mantenere il loro nome utente / password protetti, che tutte le richieste che arrivano utilizzando questo nome utente / password verranno conteggiate rispetto al loro limite e se arrivano troppe richieste, il loro account potrebbe essere disabilitato. Dite loro che se incorporano il loro nome utente / password in un'app mobile, c'è il rischio che qualcuno nefasto possa rubare il nome utente / password e utilizzarlo per fare molte richieste, causando la disabilitazione del proprio account e l'interruzione della loro app mobile . Lascia che decidano se vogliono correre il rischio o meno.

• Requisiti contrattuali. Informa i tuoi clienti che è vietato condividere il loro nome utente / password con altri, e non è consentito per loro incorporare il loro nome utente / password in app che possono essere scaricati da altri. Di 'loro che se rilevi violazioni di questa politica, il loro account potrebbe essere disabilitato e potrebbero essere fatturati per eventuali costi imposti ai 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 delegare tali richieste al proprio server. In altre parole, il client deve configurare un server che conosca il nome utente / password del client, ma questo nome utente / password non deve essere incorporato 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 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 per 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 con 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 / password in app che sono accessibile agli altri).

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

Uno dei problemi che riterrò sul fronte mobile è la convalida dell'indirizzo IP. Tipicamente gli indirizzi IP mobili assegnati dalla telco verranno compensati. L'IP compensato renderà inutile il meccanismo di convalida IP adottato sul lato server.

Implementare la soluzione su Android e Iphone; Penso che l'approccio dovrebbe essere:

1. È necessario estendere l'autenticazione del server client in modalità SSL anche alla convalida del certificato client. Voglio dire, sia il client che il server usano entrambi i certificati per stabilire una sessione SSL sicura.
2. Consegna 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 diventerà difficile per un utente malintenzionato ripudiare la stessa sessione.
3. Avere implementato un AI sul server che rileva due o più sessioni simultanee avviate utilizzando lo stesso certificato client che ti consente di sapere che è avvenuto un compromesso e il server può immediatamente aggiungere o revocare il certificato per un ulteriore utilizzo.

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

La frode è valida e non può essere affrontata solo con un'implementazione tecnica, ma se hai implementato la convalida e il blocco IP escalati, non devi preoccuparti di nulla. 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 base da media a protezione sono già stati applicati per quanto riguarda il lato B2B (YOURCOMPANY - YOURCLIENT). Quello è buono. Convalida IP, SSL / TLS, Utente / Pass ecc. Ora si teme che le credenziali API utilizzate dai propri clienti per distribuire applicazioni mobili agli utenti finali possano essere imperfette in modo che un utente finale di terze parti possa sfruttare queste credenziali se l'app mobile del tuo cliente è stata sfruttata in qualche modo.

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

1. Il tuo API API JSON / REST dovrebbe contenere le tue credenziali effettive. Se stai consegnando un servizio e hai bisogno di una connessione con un gestore di rete / operatore telefonico, queste credenziali possono essere trovate anche qui. Sai cosa intendo.

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

Questo server dovrebbe anche fungere da servizio web che contiene un set di username / password che quindi si associa a un file di configurazione e passa la richiesta al SERVER API JSON / REST. Ora, YOURCLIENTS dovrebbe avere accesso a questo server sulla base della convalida / blocco IP e protetto tramite HTTPS. Il concetto è che nessuna credenziale utente / passata può essere trovata qui tranne la chiave / segreto che si associa all'API SERVER.

1. YOURCLIENT può avere una implementazione di sicurezza dalla propria parte agli utenti finali. Può essere in una forma di coppia di chiavi pubblica / privata PKI per gli sviluppatori o un 2FA per gli 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 su un'applicazione mobile creata da uno di YOURCLIENT e ha ottenuto le proprie credenziali:

1. inutile. Per quanto riguarda l'utilizzo delle credenziali, il tuo IP verrà convalidato.
2. non valido. Per quanto riguarda il fatto che devi essere stato autenticato tramite una coppia di chiavi pubblica / privata.
3. La tecnica di escalation dei privilegi richiederà che utilizzi il server vero per essere considerato affidabile.
4. Lo sfruttamento del server attuale richiede tecniche artigianali che rallentano la motivazione di un aggressore.
5. Non c'è un attacco riuscito che abbia motivato la motivazione.

L'offuscamento è buono e rallenta un attacco ma è la forma minima di sicurezza. Dovresti fare affidamento su crypto che usa le chiavi.

Ricorda che non esiste una soluzione di sicurezza assoluta oltre al tuo continuo sforzo per combattere le frodi da una prospettiva di sicurezza tecnica e operativa.

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

Come hai detto, stai usando REST. Poche cose dovrebbero aiutarti, spero.

1. Autentica gli utenti dal lato server. Mantenere una gestione delle sessioni rigorosa in modo che non possa essere falsificato. Controlla OWASP per questo.
2. Esegui un test fuzz per la tua API. ReST è noto per alcune vulnerabilità. Si prega di esplorarli su Internet e conoscere la maggior parte dei bug noti in ReST. Patch questi problemi per la tua API.
3. La tua cosa SSL è buona che protegge i tuoi dati nel mezzo.

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