Se utilizzo solo l'autenticazione basata su nome utente / password non saranno abbastanza sicuri?
No, perché si identifica solo l' OMS sta accedendo al server API, ma non l' COSA sta accedendo.
La differenza tra CHI e COSA è l'accesso al server API
Per comprendere meglio le differenze tra WHO e COSA stanno accedendo a un server API, usiamo questa immagine:
Il canale di comunicazione previsto rappresenta l'app mobile utilizzata come previsto, da un utente legittimo senza intenzioni dannose, utilizzando una versione non manomessa dell'app mobile e comunicando direttamente con il server API senza essere attaccati da uomo nel mezzo.
Il canale effettivo può rappresentare diversi scenari diversi, come un utente legittimo con intenzioni dannose che potrebbe utilizzare una versione riconfezionata dell'app mobile, un hacker che utilizza la versione originale dell'app mobile, mentre un uomo nel mezzo l'attacca, per capire come la comunicazione tra l'app mobile e il server API viene eseguita per poter automatizzare gli attacchi contro la tua API. Sono possibili molti altri scenari, ma non li enumereremo qui.
Spero che a questo punto abbiate già un'idea del perché l' OMS e il COSA non sono la stessa cosa, ma in caso contrario diventerà chiaro in un attimo.
L' OMS è l'utente dell'app mobile che possiamo autenticare, autorizzare e identificare in diversi modi, come utilizzando OpenID Connect o flussi OAUTH2.
OAuth
In genere, OAuth fornisce ai client un "accesso delegato sicuro" alle risorse del server per conto del proprietario della risorsa. Specifica un processo per i proprietari delle risorse per autorizzare l'accesso di terze parti alle risorse del server senza condividere le proprie credenziali. Progettato specificamente per funzionare con il protocollo HTTP (Hypertext Transfer Protocol), OAuth consente essenzialmente di emettere token di accesso a client di terze parti da un server di autorizzazione, con l'approvazione del proprietario della risorsa. La terza parte utilizza quindi il token di accesso per accedere alle risorse protette ospitate dal server di risorse.
OpenID Connect
OpenID Connect 1.0 è un semplice livello di identità in cima al protocollo OAuth 2.0. Consente ai Clienti di verificare l'identità dell'Utente finale in base all'autenticazione eseguita da un Server di autorizzazione, nonché di ottenere informazioni di base sul profilo dell'Utente finale in modo interoperabile e simile a REST.
Sebbene l'autenticazione dell'utente possa consentire al server API di sapere CHI sta utilizzando l'API, non può garantire che le richieste abbiano avuto origine da COSA ti aspetti, la versione originale dell'app mobile.
Ora abbiamo bisogno di un modo per identificare COSA sta chiamando il server API, e qui le cose diventano più complicate di quanto la maggior parte degli sviluppatori possa pensare. Il WHAT è la cosa che fa la richiesta al server API. È davvero un'istanza autentica dell'app mobile o è un bot, uno script automatizzato o un aggressore che fruga manualmente con il server API, utilizzando uno strumento come Postman?
Con tua sorpresa potresti scoprire che può essere uno degli utenti legittimi che utilizza una versione riconfezionata dell'app mobile o uno script automatizzato che sta cercando di gamify e sfruttare il servizio fornito dall'applicazione.
Bene, per identificare il COSA , gli sviluppatori tendono a ricorrere a una chiave API che di solito codificano nel codice della loro app mobile. Alcuni sviluppatori fanno il possibile e calcolano la chiave in fase di esecuzione nell'app mobile, quindi diventa un segreto di runtime rispetto al primo approccio quando un segreto statico è incorporato nel codice.
Il precedente articolo è stato estratto da un articolo che ho scritto, intitolato PERCHÉ LA TUA APP MOBILE HA BISOGNO DI UNA CHIAVE API? , e che puoi leggere per intero qui , questo è il primo articolo di una serie di articoli sulle chiavi API.
Archiviazione di dati sensibili nel dispositivo client
E non posso salvare quel nome utente / password nel dispositivo per ovviamente motivi di sicurezza? Devo emettere un GUID per ogni utente al momento della registrazione, salvarlo nel suo dispositivo e recuperarlo ogni volta durante una richiesta API?
Tutto ciò che salvi nel dispositivo, anche se crittografato, può essere decodificato durante il runtime con strumenti come Frida o Xposed.
frida
Inietta i tuoi script nei processi della scatola nera. Aggancia qualsiasi funzione, spia le API crittografiche o traccia il codice di applicazioni private, non è necessario alcun codice sorgente. Modifica, premi Salva e visualizza immediatamente i risultati. Tutto senza passaggi di compilazione o riavvio del programma.
Xposed
Xposed è un framework per moduli in grado di modificare il comportamento del sistema e delle app senza toccare alcun APK. È fantastico perché significa che i moduli possono funzionare per diverse versioni e persino ROM senza alcuna modifica (purché il codice originale
In un dispositivo che l'attaccante controlla può anche utilizzare un proxy per eseguire un Man in the Middle Attack per estrarre qualsiasi segreto tu possa usare per identificare il COSA o l' OMS come mostro nell'articolo Rubare quella chiave API con un Man in the Attack :
Sebbene sia possibile utilizzare tecniche avanzate, come JNI / NDK, per nascondere la chiave API nel codice dell'app mobile, ciò non impedirà a qualcuno di eseguire un attacco MitM per rubare la chiave API. In effetti, un attacco MitM è facile al punto che può essere ottenuto anche da non sviluppatori.
Quindi ora cosa ... Sono condannato al punto da non poter proteggere il mio server API da abusi ??? Nessun silenzio quindi ... la speranza esiste ancora !!!
Possibili soluzioni
Qualcuno può dirmi quale metodo utilizzano famose applicazioni Android come Facebook, FourSquare o Twitter per autenticare ogni richiesta proveniente dalla loro applicazione mobile sul loro server?
Scusa ma non ho abbastanza conoscenze su questa app per poterti spiegare, ma posso indicarti altri approcci.
Quali altri modelli sono disponibili e quali sono i più efficienti e sicuri, ho solo bisogno di un flusso di processo per questo.
Quindi tutto ciò che viene eseguito sul lato client e necessita di qualche segreto per accedere a un'API può essere utilizzato in modi diversi e puoi saperne di più su questa serie di articoli sulle tecniche di sicurezza delle API mobili. Questo articolo ti insegnerà come utilizzare chiavi API, token di accesso utente, HMAC e TLS Pinning per proteggere l'API e come aggirarli.
Per risolvere il problema di COSA sta accedendo alla tua app mobile devi utilizzare una o tutte le soluzioni menzionate nella serie di articoli sulle tecniche di sicurezza delle API mobili che ho menzionato sopra e ho accettato che possono solo rendere più difficile l'accesso non autorizzato al tuo server API bypass ma non impossibile.
Una soluzione migliore può essere impiegata utilizzando una soluzione di attestazione dell'app mobile che consentirà al server API di sapere che sta ricevendo solo richieste da un'app mobile autentica.
Attestazione per app mobile
L'utilizzo di una soluzione di attestazione dell'app mobile consentirà al server API di sapere COSA sta inviando le richieste, consentendo così di rispondere solo alle richieste provenienti da un'app mobile autentica rifiutando tutte le altre richieste da fonti non sicure.
Il ruolo di una soluzione di attestazione dell'app mobile è garantire in fase di esecuzione che la tua app mobile non sia stata manomessa, non sia in esecuzione su un dispositivo rooted, non sia strumentata da un framework come xPosed o Frida, non sia attaccata da MitM e questo si ottiene eseguendo un SDK in background. Il servizio in esecuzione nel cloud metterà alla prova l'app e, in base alle risposte, attesterà l'integrità dell'app mobile e del dispositivo in esecuzione, quindi l'SDK non sarà mai responsabile di alcuna decisione.
In caso di corretta attestazione dell'integrità dell'app mobile, viene emesso un token JWT di breve durata e firmato con un segreto che solo il server API e il servizio di attestazione dell'app mobile nel cloud sono a conoscenza. In caso di errore sull'attestazione dell'app mobile il token JWT viene firmato con un segreto che il server API non conosce.
Ora l'App deve inviare con ogni chiamata API il token JWT nelle intestazioni della richiesta. Ciò consentirà al server API di servire solo le richieste quando può verificare la firma e l'ora di scadenza nel token JWT e rifiutarle quando fallisce la verifica.
Una volta che il segreto utilizzato dal servizio di attestazione dell'app mobile non è noto dall'app mobile, non è possibile decodificarlo in fase di esecuzione anche quando l'app viene manomessa, in esecuzione in un dispositivo rooted o comunicando su una connessione che è il bersaglio di un Man in the Middle Attack.
Il servizio di attestazione dell'app mobile esiste già come soluzione SAAS presso Approov (lavoro qui) che fornisce SDK per diverse piattaforme, tra cui iOS, Android, React Native e altre. L'integrazione richiederà anche un piccolo controllo nel codice del server API per verificare il token JWT emesso dal servizio cloud. Questo controllo è necessario affinché il server API sia in grado di decidere quali richieste servire e quali negare.
Conclusione
Alla fine, la soluzione da utilizzare per proteggere il tuo server API deve essere scelta in base al valore di ciò che stai cercando di proteggere e ai requisiti legali per quel tipo di dati, come le normative GDPR in Europa.
VUOI FARE UN MIGLIO EXTRA?
OWASP Mobile Security Project - Top 10 rischi
Il progetto OWASP Mobile Security è una risorsa centralizzata intesa a fornire agli sviluppatori e ai team di sicurezza le risorse necessarie per creare e mantenere applicazioni mobili sicure. Attraverso il progetto, il nostro obiettivo è classificare i rischi per la sicurezza mobile e fornire controlli di sviluppo per ridurne l'impatto o la probabilità di sfruttamento.
