Comunicazioni in chiaro

Categoria OWASP: MASVS-NETWORK: Network Communication

Panoramica

Se consenti comunicazioni di rete in chiaro in un'app per Android, chiunque monitori il traffico di rete può visualizzare e manipolare i dati trasmessi. Si tratta di una vulnerabilità se i dati trasmessi includono informazioni sensibili come password, numeri di carte di credito o altre informazioni personali.

Indipendentemente dal fatto che tu stia inviando o meno informazioni sensibili, l'utilizzo del testo non cifrato può comunque essere una vulnerabilità, in quanto il traffico non cifrato può essere manipolato anche tramite attacchi di rete come ARP o DNS poisoning, consentendo potenzialmente agli utenti malintenzionati di influenzare il comportamento di un'app.

Impatto

Quando un'applicazione Android invia o riceve dati in testo non cifrato su una rete, chiunque monitori la rete può intercettare e leggere questi dati. Se questi dati includono informazioni sensibili come password, numeri di carte di credito o messaggi personali, ciò può comportare furto d'identità, attività fraudolenta finanziaria e altri gravi problemi.

Ad esempio, un'app che trasmette password in testo non crittografato potrebbe esporre queste credenziali a un utente malintenzionato che intercetta il traffico. Questi dati potrebbero poi essere utilizzati per ottenere l'accesso non autorizzato agli account dell'utente.

Rischio: canali di comunicazione non criptati

La trasmissione di dati tramite canali di comunicazione non criptati espone i dati condivisi tra il dispositivo e gli endpoint dell'applicazione. Tali dati possono essere intercettati e potenzialmente modificati da un utente malintenzionato.

Mitigazioni

I dati devono essere inviati tramite canali di comunicazione criptati. I protocolli sicuri dovrebbero essere utilizzati in alternativa ai protocolli che non offrono funzionalità di crittografia.

Rischi specifici

Questa sezione raccoglie i rischi che richiedono strategie di mitigazione non standard o che sono stati mitigati a un determinato livello di SDK e sono riportati per completezza.

Rischio: HTTP

Le indicazioni in questa sezione si applicano solo alle app destinate ad Android 8.1 (livello API 27) o versioni precedenti. A partire da Android 9 (livello API 28), i client HTTP come URLConnection, Cronet e OkHttp prevedono l'utilizzo di HTTPS, pertanto il supporto del testo in chiaro è disattivato per impostazione predefinita. Tuttavia, tieni presente che è improbabile che altre librerie client HTTP come Ktor applichino queste limitazioni al testo non cifrato e devono essere utilizzate con cautela.

Mitigazioni

Utilizza la funzionalità NetworkSecurityConfig.xml per disattivare il traffico di testo non criptato e applicare HTTPS per la tua app, con eccezioni solo per i domini specifici obbligatori (di solito a scopo di debug):

Xml

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">debug.domain.com</domain>
    </domain-config>
</network-security-config>

Questa opzione consente di evitare regressioni accidentali nelle app a causa di modifiche agli URL forniti da origini esterne come i server di backend.

Rischio: FTP

L'utilizzo del protocollo FTP per lo scambio di file tra dispositivi presenta diversi rischi, tra i quali il più significativo è la mancanza di crittografia sul canale di comunicazione. È preferibile utilizzare alternative più sicure come SFTP o HTTPS.

Mitigazioni

Quando implementi meccanismi di scambio di dati su internet nella tua applicazione, dovresti utilizzare un protocollo sicuro, come HTTPS. Android mette a disposizione un insieme di API che consente agli sviluppatori di creare una logica client-server. Questo può essere protetto utilizzando Transport Layer Security (TLS), assicurando che lo scambio di dati tra due endpoint sia criptato, impedendo così agli utenti malintenzionati di intercettare le comunicazioni e recuperare dati sensibili.

In genere, le architetture client-server si basano su API di proprietà degli sviluppatori. Se la tua applicazione dipende da un insieme di endpoint API, assicurati una sicurezza approfondita seguendo queste best practice per proteggere le comunicazioni HTTPS:

  • Autenticazione: gli utenti devono autenticarsi utilizzando meccanismi sicuri come OAuth 2.0. L'autenticazione di base è generalmente sconsigliata, in quanto non fornisce meccanismi di gestione della sessione e, se le credenziali vengono archiviate in modo improprio, possono essere decodificate da Base64.
  • Autorizzazione: gli utenti devono essere limitati ad accedere solo alle risorse previste in base al principio del privilegio minimo. Questo può essere implementato adottando soluzioni di controllo dell'accesso attente per le risorse dell'applicazione.
  • Assicurati di utilizzare suite di crittografia più recenti e ponderate, seguendo le best practice per la sicurezza. Ad esempio, valuta la possibilità di supportare il protocollo TLSv1.3 con compatibilità con le versioni precedenti, se necessario, per le comunicazioni HTTPS.

Rischio: protocolli di comunicazione personalizzati

L'implementazione di protocolli di comunicazione personalizzati o il tentativo di implementare manualmente quelli ben noti può essere pericoloso.

Sebbene i protocolli personalizzati consentano agli sviluppatori di personalizzare una soluzione unica che si adatti alle esigenze previste, qualsiasi errore durante il processo di sviluppo può potenzialmente generare vulnerabilità di sicurezza. Ad esempio, gli errori nello sviluppo di meccanismi di gestione delle sessioni possono potenzialmente consentire agli attaccanti di intercettare le comunicazioni e recuperare informazioni sensibili al volo.

D'altra parte, l'implementazione di protocolli ben noti come HTTPS senza utilizzare il sistema operativo o librerie di terze parti ben mantenute aumenta la probabilità di introdurre errori di codifica che potrebbero rendere difficile, se non impossibile, aggiornare il protocollo implementato in caso di necessità. Inoltre, ciò può introdurre lo stesso tipo di vulnerabilità di sicurezza dell'utilizzo di protocolli personalizzati.

Mitigazioni

Usa le librerie gestite per implementare protocolli di comunicazione conosciuti

Per implementare protocolli noti come HTTPS nella tua applicazione, è necessario utilizzare librerie del sistema operativo o librerie di terze parti gestite.

In questo modo, gli sviluppatori hanno la certezza di optare per soluzioni che sono state ben testate, sono state migliorate nel tempo e ricevono continuamente aggiornamenti della sicurezza per correggere le vulnerabilità comuni.

Inoltre, scegliendo protocolli ben noti, gli sviluppatori beneficiano di un'ampia compatibilità su vari sistemi, piattaforme e IDE, riducendo la probabilità di errori umani durante il processo di sviluppo.

Utilizzare SFTP

Questo protocollo cripta i dati in transito. Quando utilizzi questo tipo di protocollo di scambio di file, devono essere prese in considerazione misure aggiuntive:

  • SFTP supporta diversi tipi di autenticazione. Anziché l'autenticazione basata su password, deve essere utilizzato il metodo di autenticazione con chiave pubblica. Queste chiavi devono essere create e archiviate in modo sicuro. Per questo scopo, è consigliato l'utilizzo di Android Keystore.
  • Assicurati che le crittografie supportate rispettino le best practice per la sicurezza.

Risorse