MITM-aanvallen in mobiele apps — wat het is, typen en bescherming tegen onderschepping

Wat is een MITM-aanval?

Man-in-the-Middle (MITM) — een type cyberaanval waarbij een cybercrimineel heimelijk het communicatiekanaal tussen twee partijen infiltreert. De cybercrimineel kan verzonden gegevens onderscheppen, lezen en wijzigen, terwijl hij voor beide partijen onzichtbaar blijft.

In mobiele apps zijn MITM-aanvallen bijzonder gevaarlijk omdat apparaten constant verbinding maken met verschillende netwerken — thuis, op kantoor, openbare Wi-Fi in cafés en luchthavens. Elke netwerkwisseling creëert potentieel een venster voor een aanval. Volgens de Verizon Mobile Security Index (2025) heeft 43% van de organisaties minstens één keer te maken gehad met MITM-aanvallen op bedrijfsmobiele apparaten.

Het grootste gevaar van MITM is de heimelijkheid: de gebruiker en server krijgen geen signalen van onderschepping. De sessie ziet er normaal uit, gegevens worden verzonden, er zijn geen certificaatfouten (als de aanvaller zijn eigen certificaat gebruikt). Detectie van de aanval is alleen mogelijk op het niveau van de netwerkinfrastructuur of met gespecialiseerde tools.

Een ontwikkelaar moet de mechanismen van MITM-aanvallen begrijpen om bescherming op app-niveau te ontwerpen, niet alleen vertrouwend op de beveiliging van de transportlaag.

Belangrijkste typen MITM-aanvallen

De classificatie van MITM-aanvallen omvat verschillende typen die verschillen in de methode van infiltratie in het communicatiekanaal. In mobiele ontwikkeling zijn drie typen het meest relevant.

ARP Spoofing in het lokale netwerk

ARP Spoofing — een techniek waarbij de aanvaller valse ARP-pakketten naar het lokale netwerk stuurt, waarbij zijn MAC-adres wordt gekoppeld aan het IP-adres van de gateway. Hierna wordt al het verkeer van het slachtoffer via het apparaat van de aanvaller geleid, die het doorstuurt naar de gateway en onzichtbaar blijft.

Voor het uitvoeren van de aanval zijn tools zoals Ettercap of BetterCAP voldoende, die ARP-spoofing automatiseren. De aanval is alleen mogelijk binnen één subnet, dus gebruikers van openbare Wi-Fi-netwerken zijn het meest kwetsbaar. Moderne netwerken met dynamische ARP-inspectie (DAI) op beheerde switches blokkeren dit type aanval.

Bescherming op app-niveau tegen ARP Spoofing is onmogelijk — dit is een probleem van de netwerkinfrastructuur. De app kan echter afwijkingen in de netwerkverbinding detecteren met behulp van bibliotheken zoals TrustKit voor iOS of Network Security Config voor Android.

DNS Spoofing en verkeersonderschepping

DNS Spoofing (of DNS Cache Poisoning) — vervalsing van DNS-records op het pad van de client naar de DNS-server. De aanvaller onderschept het DNS-verzoek van de app en retourneert een vals IP-adres, waardoor het verkeer naar zijn eigen server wordt geleid in plaats van naar de legitieme.

De aanval is bijzonder effectief in openbare netwerken waar de DNS-server automatisch wordt toegewezen via DHCP. De aanvaller kan zijn eigen DNS-server configureren die valse IP-adressen retourneert voor doeldomeinen. De gebruiker ziet een legitieme URL in de browser, maar maakt verbinding met de server van de aanvaller.

Bescherming tegen DNS Spoofing aan de app-kant wordt gerealiseerd via DNS-over-HTTPS (DoH) of DNS-over-TLS (DoT), die DNS-verzoeken versleutelen. Android 9+ en iOS 14+ ondersteunen systeem-DoH, de app kan deze optie expliciet inschakelen.

SSL Stripping — omzeilen van HTTPS

SSL Stripping — een aanval waarbij de aanvaller een beveiligde HTTPS-verbinding degradeert naar onbeveiligd HTTP. De techniek maakt gebruik van het feit dat veel gebruikers handmatig example.com typen in plaats van https://example.com, en de eerste verbinding wordt via HTTP tot stand gebracht.

Tools zoals sslstrip (Moxie Marlinspike, 2009) en bettercap onderscheppen automatisch HTTP-verzoeken, brengen een HTTPS-verbinding met de server tot stand namens zichzelf en sturen het ontsleutelde verkeer via HTTP naar de client. De browser toont geen hangsloticoon — de gebruiker weet niet dat de verbinding niet beveiligd is.

Moderne bescherming — HTTP Strict Transport Security (HSTS): de server informeert de browser dat alle toekomstige verbindingen alleen via HTTPS moeten zijn. HSTS Preload List beschermt extra tegen de eerste aanval, maar vereist voorafgaande registratie van het domein.

Hoe werkt een MITM-aanval in mobiele apps

Een typische MITM-aanval op een mobiele app doorloopt vier fasen. Elke fase maakt gebruik van verschillende kwetsbaarheden en voor volledige bescherming moeten alle vectoren worden geblokkeerd.

Eerste fase — infiltratie: de aanvaller bevindt zich op het pad van het verkeer tussen het apparaat en de server. Dit kan ARP Spoofing in het lokale netwerk zijn, een vals Wi-Fi-punt (Evil Twin) of compromittering van de DNS-server van de provider. Mobiele apparaten zijn bijzonder kwetsbaar bij automatische verbinding met open netwerken.

Tweede fase — onderschepping: na infiltratie begint de aanvaller alle pakketten te lezen die de app en server uitwisselen. In deze fase verzamelt hij metadata: verzoek-URL's, pakketgroottes, cookies, headers. Zelfs als gegevens versleuteld zijn, kunnen metadata de structuur en bedrijfslogica van de app onthullen.

Derde fase — ontsleuteling (als verkeer versleuteld is): de aanvaller brengt twee TLS-verbindingen tot stand — één met de server (met een vals certificaat), één met de client. De app beschouwt de verbinding als veilig, maar de aanvaller ziet alle gegevens in platte tekst. Zonder Certificate Pinning werkt dit voor elk certificaat dat in het systeemarchief is geïnstalleerd.

Vierde fase — wijziging en exfiltratie: de aanvaller kan niet alleen lezen, maar ook verzonden gegevens wijzigen. In financiële apps kan dit betekenen dat het rekeningnummer van de ontvanger wordt gewijzigd, in API-verzoeken — wijziging van autorisatieparameters. iOS en Android raden aan om integriteitscontrole van antwoorden op app-niveau te implementeren.

Codevoorbeelden: bescherming tegen onderschepping op Android en iOS

Laten we praktische voorbeelden bekijken van bescherming tegen MITM-aanvallen met Certificate Pinning in Kotlin en Swift. Deze voorbeelden blokkeren certificaatvervanging zelfs bij een gecompromitteerd systeemarchief.

Certificate Pinning op Android (OkHttp)

OkHttp — de standaard HTTP-bibliotheek voor Android die CertificatePinner ondersteunt. Specificeer de SHA-256-hash van het certificaat van uw server — alle andere certificaten worden geweigerd.

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 op iOS (URLSession)

Op iOS gebruikt u URLSessionDelegate voor handmatige verificatie van het servercertificaat. Vergelijk SecCertificateRef met de lokaal opgeslagen kopie.

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 op Android

Android ondersteunt declaratieve bescherming via het XML-bestand network_security_config.xml, dat verkeer op OS-niveau blokkeert zonder code te schrijven.

<!-- 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>

Methoden om mobiele apps tegen MITM te beschermen

Uitgebreide bescherming tegen MITM-aanvallen omvat maatregelen op app-, server- en netwerkinfrastructuurniveau. Hieronder staan de belangrijkste aanbevelingen voor Android en iOS.

Gebruik Certificate Pinning — het vastpinnen van het servercertificaat in de app-code. In tegenstelling tot standaard TLS-verificatie die elk certificaat uit het systeemarchief vertrouwt, controleert Certificate Pinning een specifiek certificaat of de openbare sleutel ervan. OkHttp op Android en TrustKit op iOS bieden kant-en-klare implementaties van dit mechanisme.

Forceer HTTPS en HSTS: alle netwerkverzoeken moeten via HTTPS gaan en de server moet de Strict-Transport-Security-header retourneren. Voeg voor Android android:usesCleartextTraffic="false" toe aan het manifest — dit verbiedt HTTP-verbindingen op OS-niveau. iOS verbiedt standaard HTTP vanaf iOS 9 via App Transport Security (ATS).

Implementeer integriteitscontrole van antwoorden: onderteken serverantwoorden met een digitale handtekening die de app controleert. Zelfs als de aanvaller HTTPS-verkeer onderschept (via een proxy met herinstallatie van het certificaat), kan hij de handtekening niet vervalsen zonder de privésleutel van de server. Gebruik JWT met RS256 of HMAC-handtekeningen voor kritieke bewerkingen.

Schakel aan de serverzijde HTTP Public Key Pinning (HPKP) in — een richtlijn die de browser of app vertelt welk certificaat als geldig moet worden beschouwd voor een bepaald domein. HPKP vereist echter voorzichtigheid: onjuiste configuratie kan de toegang tot de app voor lange tijd blokkeren. Google raadt aan HPKP alleen in combinatie met back-upcertificaten te gebruiken.

Volgens NIST SP 800-52 Rev. 2 (2024) elimineert de combinatie van TLS 1.3, Certificate Pinning en HSTS 99% van de bekende vectoren van MITM-aanvallen op mobiele apps. Ontwikkelaars wordt aangeraden de bescherming te testen met tools zoals mitmproxy voordat de app wordt gepubliceerd.