Categoria OWASP: MASVS-PLATFORM: Platform Interaction
Panoramica
Molte applicazioni mobile utilizzano un'API esterna per fornire funzionalità. Tradizionalmente, per autenticare l'applicazione che si connette al servizio viene utilizzato un token o una chiave statici.
Tuttavia, nel contesto di un'impostazione client-server (o di un'app mobile e un'API), l'utilizzo di una chiave statica non è generalmente considerato un metodo di autenticazione sicuro per accedere a dati o servizi sensibili. A differenza dell'infrastruttura interna, chiunque può accedere a un'API esterna e abusare del servizio se ha accesso a questa chiave.
Ad esempio, è possibile che una chiave statica venga sottoposta a reverse engineering dall'applicazione o intercettata quando un'applicazione mobile comunica con l'API esterna. Inoltre, è più probabile che questa chiave statica venga codificata all'interno dell'applicazione.
Il rischio per i dati e i servizi API si verifica quando non vengono utilizzati controlli di autenticazione e accesso sufficientemente sicuri.
Quando si utilizza una chiave statica, l'API può essere sfruttata riproducendo le richieste o costruendo nuove richieste utilizzando la chiave (intercettata o sottoposta a reverse engineering) senza limiti di tempo.
Impatto
Se uno sviluppatore paga un servizio API AI o ML, per un malintenzionato sarebbe relativamente facile rubare questa chiave e accumulare debiti sul suo servizio o utilizzarla per creare contenuti falsi.
Qualsiasi dato utente, file o PII memorizzati nell'API sarebbe disponibile liberamente, con conseguenti fughe di dati dannose.
Un malintenzionato potrebbe anche utilizzare questo accesso per commettere frodi, reindirizzare i servizi e, in rari casi, ottenere il controllo completo dei server.
Mitigazioni
API stateful
Se l'applicazione fornisce un accesso utente o ha la possibilità di monitorare le sessioni utente, consigliamo agli sviluppatori di utilizzare un servizio API come Google Cloud per l'integrazione stateful con la propria app.
Inoltre, utilizza l'autenticazione sicura, la convalida del client e i controlli della sessione forniti dal servizio API e valuta la possibilità di utilizzare un token dinamico come alternativa a una chiave statica. Assicurati che il token scada in un periodo di tempo ragionevolmente breve (in genere 1 ora).
Il token dinamico deve quindi essere utilizzato per l'autenticazione per fornire l'accesso all'API. Queste linee guida mostrano come è possibile ottenere questo risultato utilizzando OAuth 2.0. Oltre a queste linee guida, OAuth 2.0 può essere ulteriormente rafforzato per ridurre le vulnerabilità nella tua app per Android implementando le seguenti funzionalità.
Implementa la gestione e il logging degli errori corretti:
- Gestisci gli errori OAuth in modo controllato e visibile e registrali a scopo di debug.
- Una superficie di attacco ridotta ti aiuterà anche a identificare e risolvere eventuali problemi che potrebbero sorgere.
- Assicurati che tutti i messaggi registrati o presentati all'utente siano chiari, ma non contengano informazioni utili a un malintenzionato.
Configura OAuth in modo sicuro nell'applicazione:
- Invia il parametro
redirect_urisia all'endpoint di autorizzazione sia a quello del token. - Se la tua app utilizza OAuth con un servizio di terze parti, configura la condivisione delle risorse tra origini (CORS) per limitare l'accesso alle risorse della tua app.
- In questo modo, puoi impedire attacchi cross-site scripting (XSS) non autorizzati.
- Utilizza il parametro state per prevenire attacchi CSRF.
Utilizza una libreria di sicurezza:
- Prendi in considerazione l'utilizzo di una libreria di sicurezza come AppAuth per semplificare
l'implementazione di flussi OAuth sicuri.
- Queste librerie Android possono contribuire ad automatizzare molte delle best practice di sicurezza menzionate in precedenza.
Altri metodi di autenticazione, inclusi i token Firebase e Google ID, sono descritti nella documentazione OpenAPI.
API stateless
Se il servizio API non offre nessuna delle protezioni consigliate in precedenza e esiste un requisito per sessioni stateless senza accesso utente, gli sviluppatori potrebbero dover fornire le proprie soluzioni middleware.
Ciò comporterebbe il "proxy" delle richieste tra l'app e l'endpoint API. Un modo per farlo è utilizzare i token web JSON (JWT) e la firma web JSON (JWS) oppure fornire un servizio completamente autenticato come consigliato in precedenza. In questo modo, la chiave statica vulnerabile viene archiviata lato server anziché nell'applicazione (client).
Esistono problemi intrinseci con la fornitura di una soluzione stateless end-to-end nelle applicazioni mobile. Alcune delle sfide più importanti sono la convalida del client (app) e l'archiviazione sicura della chiave privata o del segreto sul dispositivo.
L'API Play Integrity fornisce la convalida dell'integrità dell'applicazione e delle richieste. In questo modo, è possibile mitigare alcuni scenari in cui questo accesso può essere utilizzato in modo improprio. Per quanto riguarda la gestione delle chiavi, in molti casi il keystore è la posizione migliore per l'archiviazione sicura delle chiavi private.
Alcune applicazioni mobile utilizzano una fase di registrazione per verificare l'integrità dell'applicazione e fornire una chiave tramite uno scambio sicuro. Questi metodi sono complessi e non rientrano nell'ambito di questo documento. Tuttavia, un servizio di gestione delle chiavi cloud è una potenziale soluzione.