Attacchi MITM nelle app mobili — cosa sono, tipi e protezione dall'intercettazione

Cos'è un attacco MITM?

Man-in-the-Middle (MITM) è un tipo di attacco informatico in cui un aggressore si inserisce segretamente in un canale di comunicazione tra due parti. L'aggressore può intercettare, leggere e modificare i dati trasmessi rimanendo invisibile a entrambe le parti.

Nelle app mobili, gli attacchi MITM sono particolarmente pericolosi perché i dispositivi si connettono costantemente a varie reti — casa, ufficio, Wi-Fi pubblico in caffè e aeroporti. Ogni cambio di rete crea potenzialmente una finestra per l'attacco. Secondo Verizon Mobile Security Index (2025), il 43% delle organizzazioni ha riscontrato attacchi MITM su dispositivi mobili aziendali almeno una volta.

Il pericolo principale del MITM è la furtività: utente e server non ricevono segnali di intercettazione. La sessione sembra normale, i dati vengono trasmessi, non ci sono errori di certificato (se l'aggressore usa il proprio certificato). L'attacco può essere rilevato solo a livello di infrastruttura di rete o con strumenti specializzati.

Uno sviluppatore deve comprendere i meccanismi degli attacchi MITM per progettare la protezione a livello di applicazione, anziché affidarsi esclusivamente alla sicurezza del livello di trasporto.

Principali tipi di attacchi MITM

La classificazione degli attacchi MITM include diversi tipi che differiscono per il metodo di inserimento nel canale di comunicazione. Nello sviluppo mobile, tre tipi sono i più rilevanti.

ARP Spoofing nella rete locale

L'ARP Spoofing è una tecnica in cui l'aggressore invia pacchetti ARP falsi alla rete locale, associando il proprio indirizzo MAC all'indirizzo IP del gateway. Dopo di che, tutto il traffico della vittima viene instradato attraverso il dispositivo dell'aggressore, che lo inoltra al gateway rimanendo invisibile.

Strumenti come Ettercap o BetterCAP sono sufficienti per condurre l'attacco, poiché automatizzano l'ARP spoofing. L'attacco è possibile solo all'interno di una singola sottorete, rendendo gli utenti delle reti Wi-Fi pubbliche i più vulnerabili. Le reti moderne con Dynamic ARP Inspection (DAI) su switch gestiti bloccano questo tipo di attacco.

La protezione a livello di applicazione dall'ARP Spoofing è impossibile — questo è un problema dell'infrastruttura di rete. Tuttavia, l'applicazione può rilevare anomalie nella connettività di rete utilizzando librerie come TrustKit per iOS o Network Security Config per Android.

DNS Spoofing e intercettazione del traffico

Il DNS Spoofing (o avvelenamento della cache DNS) è la sostituzione di record DNS nel percorso dal client al server DNS. L'aggressore intercetta la richiesta DNS dell'applicazione e restituisce un indirizzo IP falso, reindirizzando il traffico verso il proprio server invece del server legittimo.

L'attacco è particolarmente efficace nelle reti pubbliche dove il server DNS viene assegnato automaticamente tramite DHCP. L'aggressore può configurare un proprio server DNS che restituisce indirizzi IP falsificati per i domini target. L'utente vede un URL legittimo nel browser ma si connette al server dell'aggressore.

La protezione dal DNS Spoofing sul lato applicazione è implementata tramite DNS-over-HTTPS (DoH) o DNS-over-TLS (DoT), che crittografano le query DNS. Android 9+ e iOS 14+ supportano DoH a livello di sistema e l'applicazione può abilitare esplicitamente questa opzione.

SSL Stripping — bypass di HTTPS

L'SSL Stripping è un attacco in cui l'aggressore declassa una connessione HTTPS sicura a HTTP non sicuro. La tecnica sfrutta il fatto che molti utenti digitano manualmente example.com invece di https://example.com e la prima connessione viene stabilita tramite HTTP.

Strumenti come sslstrip (Moxie Marlinspike, 2009) e bettercap intercettano automaticamente le richieste HTTP, stabiliscono una connessione HTTPS con il server per proprio conto e passano il traffico decifrato al client tramite HTTP. Il browser non mostra l'icona del lucchetto — l'utente non sa che la connessione non è sicura.

Protezione moderna — HTTP Strict Transport Security (HSTS): il server comunica al browser che tutte le future connessioni devono avvenire solo tramite HTTPS. L'elenco di precaricamento HSTS protegge inoltre dal primo attacco, ma richiede la registrazione preventiva del dominio.

Come funziona un attacco MITM nelle app mobili

Un tipico attacco MITM su un'app mobile attraversa quattro fasi. Ogni fase sfrutta diverse vulnerabilità e la protezione completa richiede di coprire tutti i vettori.

La prima fase è l'inserimento: l'aggressore si pone nel percorso del traffico tra dispositivo e server. Può essere ARP Spoofing nella rete locale, un punto di accesso Wi-Fi falso (Evil Twin) o il compromesso del server DNS del fornitore. I dispositivi mobili sono particolarmente vulnerabili quando si connettono automaticamente a reti aperte.

La seconda fase è l'intercettazione: dopo l'inserimento, l'aggressore inizia a leggere tutti i pacchetti scambiati tra l'app e il server. In questa fase, raccoglie metadati: URL delle richieste, dimensioni dei pacchetti, cookie, intestazioni. Anche se i dati sono crittografati, i metadati possono rivelare la struttura dell'applicazione e la logica di business.

La terza fase è la decifratura (se il traffico è crittografato): l'aggressore stabilisce due connessioni TLS — una con il server (usando un certificato falsificato), un'altra con il client. L'app considera la connessione sicura, ma l'aggressore vede tutti i dati in chiaro. Senza Certificate Pinning, questo funziona per qualsiasi certificato installato nell'archivio di sistema.

La quarta fase è la modifica e l'esfiltrazione: l'aggressore può non solo leggere ma anche modificare i dati trasmessi. Nelle app finanziarie, ciò potrebbe significare cambiare il numero di conto del destinatario; nelle richieste API, modificare i parametri di autorizzazione. iOS e Android raccomandano di implementare controlli di integrità delle risposte a livello di applicazione.

Esempi di codice: protezione dall'intercettazione su Android e iOS

Vediamo esempi pratici di protezione dagli attacchi MITM utilizzando Certificate Pinning in Kotlin e Swift. Questi esempi bloccano la sostituzione del certificato anche se l'archivio di sistema è compromesso.

Certificate Pinning su Android (OkHttp)

OkHttp è la libreria HTTP standard per Android che supporta CertificatePinner. Specifica l'hash SHA-256 del certificato del tuo server — qualsiasi altro certificato verrà rifiutato.

import okhttp3.CertificatePinner
import okhttp3.OkHttpClient

val certificatePinner = CertificatePinner.Builder()
    .add(
        "api.example.com",
        "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
    )
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

Certificate Pinning su iOS (URLSession)

Su iOS, usa URLSessionDelegate per verificare manualmente il certificato del server. Confronta SecCertificateRef con una copia salvata localmente.

class SessionDelegate: NSObject, URLSessionDelegate {
    func urlSession(
        _ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (
            URLSession.AuthChallengeDisposition,
            URLCredential?
        ) -> Void
    ) {
        guard let serverTrust = challenge.protectionSpace
            .serverTrust else { return }

        let pinnedCert = SecCertificateCreateWithData(
            nil,
            pinnedCertData as CFData
        )

        let serverCerts = (0..<SecTrustGetCertificateCount(serverTrust))
            .compactMap { SecTrustGetCertificateAtIndex(serverTrust, $0) }

        if serverCerts.contains { CFEqual($0, pinnedCert) } {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

Network Security Config su Android

Android supporta la protezione dichiarativa tramite il file network_security_config.xml, che blocca il traffico a livello di sistema operativo senza scrivere codice.

<!-- network_security_config.xml -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-07-01">
            <pin digest="SHA-256">AAAAAAAAAAAAAAAAAAAAAAAAAAAA</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Metodi di protezione delle app mobili da MITM

La protezione completa dagli attacchi MITM include misure a livello di applicazione, server e infrastruttura di rete. Di seguito sono riportate le principali raccomandazioni per Android e iOS.

Usa Certificate Pinning — associazione del certificato del server nel codice dell'applicazione. A differenza della verifica TLS standard, che si fida di qualsiasi certificato dall'archivio di sistema, Certificate Pinning verifica un certificato specifico o la sua chiave pubblica. OkHttp su Android e TrustKit su iOS forniscono implementazioni pronte all'uso di questo meccanismo.

Imponi HTTPS e HSTS: tutte le richieste di rete devono passare attraverso HTTPS e il server deve restituire l'intestazione Strict-Transport-Security. Per Android, aggiungi android:usesCleartextTraffic="false" al manifest — questo blocca le connessioni HTTP a livello di sistema operativo. iOS blocca HTTP per impostazione predefinita da iOS 9 tramite App Transport Security (ATS).

Implementa controlli di integrità delle risposte: firma le risposte del server con una firma digitale che l'app verifica. Anche se un aggressore intercetta il traffico HTTPS (tramite un proxy con reinstallazione del certificato), non può falsificare la firma senza la chiave privata del server. Usa JWT con firme RS256 o HMAC per le operazioni critiche.

Sul lato server, abilita HTTP Public Key Pinning (HPKP) — una direttiva che indica al browser o all'app quale certificato considerare valido per un dato dominio. Tuttavia, HPKP richiede cautela: una configurazione errata può bloccare l'accesso all'applicazione per un lungo periodo. Google raccomanda di usare HPKP solo in combinazione con certificati di backup.

Secondo NIST SP 800-52 Rev. 2 (2024), la combinazione di TLS 1.3, Certificate Pinning e HSTS elimina il 99% dei vettori di attacco MITM noti sulle app mobili. Si raccomanda agli sviluppatori di testare la protezione con strumenti come mitmproxy prima di pubblicare l'applicazione.