Metodo proposto per limitare l'accesso API solo all'App mobile

Sebbene sia certamente il caso che la generazione di una chiave di accesso dinamica basata sull'indirizzo IP migliorerà la protezione, ci sono una serie di problemi con questo approccio:

1. In realtà non si può presumere che l'indirizzo IP di un dispositivo mobile sia molto stabile. Ciò significherebbe che l'indirizzo IP potrebbe cambiare e quindi causare il rifiuto delle richieste. Inoltre, è necessario interrogare un altro servizio tramite un'API per scoprire anche l'indirizzo IP pubblico del dispositivo (non lo sa perché potrebbe essere dietro NAT). Alcune reti mobili moderne possono caricare le richieste di bilanciamento indirizzando più indirizzi IP, il che potrebbe significare che ottieni un IP esterno diverso per ciascuna richiesta.

2. L'algoritmo per calcolare la chiave può essere decodificato dalla tua app e quindi abusato. Quindi devi ancora preoccuparti di quanto sia ben protetto.

3. Probabilmente il più importante di tutti, questo in realtà non protegge gli abusi dallo stesso indirizzo IP (ad esempio dispositivi sulla stessa rete dietro NAT). Un utente malintenzionato deve semplicemente acquisire il buon AppKey da un attacco Man-in-the-Middle e quindi potrebbe utilizzarlo qualsiasi script o altre app che desideravano correttamente dallo stesso indirizzo IP.

A mio parere, l'approccio migliore consiste nell'incorporare un segreto nell'app che può quindi essere utilizzato in un calcolo HMAC insieme ai parametri di richiesta dell'API per mostrare che la richiesta proviene dalla tua app. Naturalmente, sei ancora soggetto alla possibilità che questo segreto venga decodificato dalla tua app. Ci sono quindi tutta una serie di protezioni diverse che potresti usare per cercare di evitarlo.

Lavoro per un'azienda specializzata in questa zona -  proteggere le API di back-end utilizzate dalle app mobili in modo che possano solo essere utilizzate dall'app ufficiale. Sareste sorpresi dai tipi di attacchi di business che possono essere montati da richieste di spoofing e dalla lunghezza a cui alcuni malintenzionati andranno per installare tali attacchi. Abbiamo una serie di blog molto dettagliata qui che ti guida attraverso tutti i diversi livelli di protezione che puoi applicare nella tua app che ritengo ti possano essere utili: link

Alcuni commenti

1. Il tuo meccanismo si basa sulla segretezza di un algoritmo, una tecnica nota come sicurezza attraverso l'oscurità , che è quasi universalmente considerato una cattiva idea .

2. Non è probabile che sarai in grado di offuscare il tuo codice abbastanza da impedire il reverse engineering, specialmente alla luce di ampia varietà di deobfuscators disponibili su Internet.

3. Anche se un hacker non può deoffuscare il tuo codice, potrebbe eseguire l'app in un ambiente di rete fittizia (dove può impostare l'indirizzo IP su qualsiasi cosa desideri), utilizzare la tua app per generare gli hash delle chiavi e usa quelli in un attacco di replay.

4. Probabilmente la tua app non conoscerà il suo indirizzo IP visibile e probabilmente il tuo servizio non conoscerà l'indirizzo IP locale dell'app, quindi sarebbe difficile far coincidere le cose. L'app potrebbe potenzialmente passare attraverso il suo indirizzo IP locale come parte della richiesta, ma ovviamente invalida l'intero meccanismo di sicurezza, dato che sarebbe banale cambiarlo.

5. Anche se il tuo meccanismo è arrivato al punto in cui è protetto, nulla impedisce a un hacker di utilizzare la tua app e di modificarne una parte al fine di eseguire il suo codice.

6. In generale è una pessima idea quella di lanciare il tuo sicurezza.

Modifica:

7. Forse il tuo meccanismo rallenterebbe il primo hacker per tentare di hackerarlo. Ma tutto ciò che serve è un ragazzo per capirlo e caricare il crack su una pagina di hacker. Quindi è game over e la tua mitigazione è inutile.

8. Poiché non si emettono le chiavi per utente, non è possibile nascondere la lista nera o bloccare alcuna chiave compromessa. Puoi solo bloccare tutti o nessuno. Ciò rende il tuo meccanismo significativamente peggiore del modello standard di emissione di chiavi per utente.

In breve, non è possibile distinguere un dispositivo sconosciuto da un altro dispositivo sconosciuto, specialmente se quest'ultimo tenta di impersonare il primo.

Il metodo standard consiste nel generare una chiave per dispositivo. Fai in modo che l'utente registri l'app come parte di un flusso di lavoro iniziale e collegalo in qualche modo all'identità dell'utente o del dispositivo.

Ora ogni connessione API ha una chiave univoca. Puoi limitare il suo utilizzo (per condividere l'accesso API in modo più equo tra i clienti), puoi eseguire la scansione dei forum haxx0r e bloccare le chiavi trovate lì, ecc.

Non è possibile fare una buona distinzione tra "mobile" e "desktop", però. Un telefono funziona tramite una connessione wifi a una rete cablata "mobile"? In tal caso, in che modo è diverso da un tablet / laptop / desktop / server che fa lo stesso? In caso contrario, come si spiega a un utente dell'app mobile che "non sta utilizzando l'accesso mobile"?