Comunicazioni in chiaro

Categoria OWASP: MASVS-NETWORK: Network Communication

Panoramica

Consentire le comunicazioni di rete in testo non criptato in un'app per Android significa che 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 di dati in chiaro può comunque essere una vulnerabilità, in quanto il traffico di dati in chiaro può essere manipolato anche tramite attacchi di rete come ARP o DNS poisoning, consentendo potenzialmente agli attaccanti di influenzare il comportamento di un'app.

Impatto

Quando un'app per Android invia o riceve dati in chiaro 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ò portare a furto di identità, frodi finanziarie e altri problemi gravi.

Ad esempio, un'app che trasmette password in testo non criptato potrebbe esporre queste credenziali a un 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 su canali di comunicazione non criptati espone i dati condivisi tra il dispositivo e gli endpoint dell'applicazione. Questi dati possono essere intercettati e potenzialmente modificati da un malintenzionato.

Mitigazioni

I dati devono essere inviati tramite canali di comunicazione criptati. I protocolli sicuri devono essere utilizzati come 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 qui per completezza.

Rischio: HTTP

Le indicazioni riportate in questa sezione si applicano solo alle app che hanno come target 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 applicano l'utilizzo di HTTPS, pertanto il supporto di testo non criptato è disattivato per impostazione predefinita. Tieni presente, tuttavia, che è improbabile che altre librerie client HTTP come Ktor applichino queste restrizioni ai dati in chiaro 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 richiesti (in genere per scopi 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 fonti esterne come i server di backend.

Rischio: FTP

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

Mitigazioni

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

In genere, le architetture client-server si basano su API di proprietà dello sviluppatore. Se la tua applicazione dipende da un insieme di endpoint API, assicurati di avere una sicurezza approfondita seguendo queste best practice per la sicurezza 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 delle sessioni e, se le credenziali vengono archiviate in modo errato, possono essere decodificate da Base64.
  • Autorizzazione: gli utenti devono essere limitati ad accedere solo alle risorse previste seguendo il principio del privilegio minimo. Questa operazione può essere implementata adottando soluzioni di controllo dell'accesso accurate per gli asset dell'applicazione.
  • Assicurati che vengano utilizzate le suite di cifratura 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 più noti può essere pericoloso.

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

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

Mitigazioni

Utilizzare librerie gestite per implementare protocolli di comunicazione noti

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

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

Inoltre, scegliendo protocolli noti, gli sviluppatori usufruiscono di un'ampia compatibilità tra 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, devi tenere in considerazione misure aggiuntive:

  • SFTP supporta diversi tipi di autenticazione. Anziché l'autenticazione basata su password, devi utilizzare il metodo di autenticazione con chiave pubblica. Queste chiavi devono essere create e archiviate in modo sicuro. A questo scopo è consigliabile utilizzare Android Keystore.
  • Assicurati che le cifrature supportate seguano le best practice per la sicurezza.

Risorse