MITM-attacker i mobila applikationer — vad det är, typer och skydd mot avlyssning

Vad är en MITM-attack?

Man-in-the-Middle (MITM) — en typ av cyberattack där en cyberbrottsling i hemlighet infiltrerar kommunikationskanalen mellan två parter. Cyberbrottslingen kan avlyssna, läsa och ändra överförda data samtidigt som han förblir osynlig för båda parter.

I mobila applikationer är MITM-attacker särskilt farliga eftersom enheter ständigt ansluter till olika nätverk — hem, kontor, offentligt Wi-Fi på kaféer och flygplatser. Varje nätverksbyte skapar potentiellt ett fönster för attack. Enligt Verizon Mobile Security Index (2025) har 43% av organisationerna minst en gång stött på MITM-attacker på företagens mobila enheter.

Den största faran med MITM — hemlighetsfullhet: användaren och servern får inga signaler om avlyssning. Sessionen ser normal ut, data överförs, inga certifikatfel uppstår (om angriparen använder sitt eget certifikat). Upptäckt av attacken är endast möjlig på nivån av nätverksinfrastruktur eller med specialiserade verktyg.

Utvecklaren måste förstå mekanismerna för MITM-attacker för att utforma skydd på applikationsnivå, inte bara förlita sig på säkerheten i transportlagret.

Huvudtyper av MITM-attacker

Klassificeringen av MITM-attacker omfattar flera typer som skiljer sig i metoden för infiltration i kommunikationskanalen. Inom mobil utveckling är tre typer mest relevanta.

ARP Spoofing i det lokala nätverket

ARP Spoofing — en teknik där angriparen skickar falska ARP-paket till det lokala nätverket, vilket kopplar sin MAC-adress till gatewayens IP-adress. Därefter dirigeras allt offerts trafik via angriparens enhet, som vidarebefordrar den till gatewayen och förblir osynlig.

För att utföra attacken räcker det med verktyg som Ettercap eller BetterCAP, som automatiserar ARP-spoofing. Attacken är endast möjlig inom ett subnät, därför är användare av offentliga Wi-Fi-nätverk mest sårbara. Moderna nätverk med dynamisk ARP-inspektion (DAI) på hanterade switchar blockerar denna typ av attack.

Skydd på applikationsnivå mot ARP Spoofing är omöjligt — detta är ett problem med nätverksinfrastrukturen. Applikationen kan dock upptäcka avvikelser i nätverksanslutningen med hjälp av bibliotek som TrustKit för iOS eller Network Security Config för Android.

DNS Spoofing och trafikavlyssning

DNS Spoofing (eller DNS Cache Poisoning) — förfalskning av DNS-poster på vägen från klienten till DNS-servern. Angriparen avlyssnar applikationens DNS-begäran och returnerar en falsk IP-adress, vilket dirigerar trafiken till sin egen server istället för den legitima.

Attacken är särskilt effektiv i offentliga nätverk där DNS-servern tilldelas automatiskt via DHCP. Angriparen kan konfigurera en egen DNS-server som returnerar falska IP-adresser för måldomäner. Användaren ser en legitim URL i webbläsaren men ansluter till angriparens server.

Skydd mot DNS Spoofing på applikationssidan realiseras via DNS-over-HTTPS (DoH) eller DNS-over-TLS (DoT), som krypterar DNS-begäranden. Android 9+ och iOS 14+ stöder system-DoH, applikationen kan explicit aktivera detta alternativ.

SSL Stripping — kringgående av HTTPS

SSL Stripping — en attack där angriparen nedgraderar en säker HTTPS-anslutning till osäker HTTP. Tekniken utnyttjar det faktum att många användare manuellt skriver example.com istället för https://example.com, och den första anslutningen upprättas via HTTP.

Verktyg som sslstrip (Moxie Marlinspike, 2009) och bettercap avlyssnar automatiskt HTTP-begäranden, upprättar en HTTPS-anslutning med servern i eget namn och överför den dekrypterade trafiken till klienten via HTTP. Webbläsaren visar inte hänglåsikonen — användaren vet inte att anslutningen inte är säker.

Modernt skydd — HTTP Strict Transport Security (HSTS): servern informerar webbläsaren om att alla framtida anslutningar endast ska ske via HTTPS. HSTS Preload List skyddar ytterligare mot den första attacken men kräver förhandsregistrering av domänen.

Hur en MITM-attack fungerar i mobila applikationer

En typisk MITM-attack på en mobil applikation går igenom fyra faser. Varje fas använder olika sårbarheter och för fullständigt skydd måste alla vektorer blockeras.

Första fasen — infiltration: angriparen befinner sig i vägen för trafiken mellan enheten och servern. Detta kan vara ARP Spoofing i det lokala nätverket, en falsk Wi-Fi-punkt (Evil Twin) eller kompromettering av leverantörens DNS-server. Mobila enheter är särskilt sårbara vid automatisk anslutning till öppna nätverk.

Andra fasen — avlyssning: efter infiltration börjar angriparen läsa alla paket som applikationen och servern utbyter. I denna fas samlar han metadata: begärans-URL:er, paketstorlekar, cookies, rubriker. Även om data är krypterad kan metadata avslöja applikationens struktur och affärslogik.

Tredje fasen — dekryptering (om trafiken är krypterad): angriparen upprättar två TLS-anslutningar — en med servern (med ett falskt certifikat), en med klienten. Applikationen anser anslutningen säker, men angriparen ser all data i klartext. Utan Certificate Pinning fungerar detta för alla certifikat installerade i systemarkivet.

Fjärde fasen — modifiering och exfiltrering: angriparen kan inte bara läsa utan även ändra överförda data. I finansiella applikationer kan detta innebära ändring av mottagarens kontonummer, i API-begäranden — ändring av auktoriseringsparametrar. iOS och Android rekommenderar implementering av integritetskontroll av svar på applikationsnivå.

Kodexempel: skydd mot avlyssning på Android och iOS

Låt oss titta på praktiska exempel på skydd mot MITM-attacker med Certificate Pinning i Kotlin och Swift. Dessa exempel blockerar certifikatbyte även vid ett komprometterat systemarkiv.

Certificate Pinning på Android (OkHttp)

OkHttp — standard HTTP-biblioteket för Android som stöder CertificatePinner. Ange SHA-256-hash av ditt servercertifikat — alla andra certifikat kommer att avvisas.

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

På iOS använder du URLSessionDelegate för manuell verifiering av servercertifikatet. Jämför SecCertificateRef med den lokalt sparade kopian.

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 på Android

Android stöder deklarativt skydd via XML-filen network_security_config.xml, som blockerar trafik på OS-nivå utan att skriva kod.

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

Metoder för att skydda mobila applikationer mot MITM

Omfattande skydd mot MITM-attacker innefattar åtgärder på applikations-, server- och nätverksinfrastrukturnivå. Nedan följer huvudrekommendationerna för Android och iOS.

Använd Certificate Pinning — fastsättning av servercertifikatet i applikationskoden. Till skillnad från standard TLS-verifiering som litar på alla certifikat från systemarkivet, kontrollerar Certificate Pinning ett specifikt certifikat eller dess publika nyckel. OkHttp på Android och TrustKit på iOS tillhandahåller färdiga implementeringar av denna mekanism.

Tvinga HTTPS och HSTS: alla nätverksbegäranden måste gå via HTTPS och servern måste returnera Strict-Transport-Security-huvudet. För Android, lägg till android:usesCleartextTraffic="false" i manifestet — detta förbjuder HTTP-anslutningar på OS-nivå. iOS förbjuder som standard HTTP från iOS 9 via App Transport Security (ATS).

Implementera integritetskontroll av svar: signera server svar med en digital signatur som applikationen verifierar. Även om angriparen avlyssnar HTTPS-trafik (via en proxy med ominstallation av certifikatet), kan han inte förfalska signaturen utan serverns privata nyckel. Använd JWT med RS256 eller HMAC-signaturer för kritiska operationer.

Aktivera HTTP Public Key Pinning (HPKP) på serversidan — en direktiv som talar om för webbläsaren eller applikationen vilket certifikat som ska anses giltigt för en viss domän. HPKP kräver dock försiktighet: felaktig konfiguration kan blockera åtkomst till applikationen under lång tid. Google rekommenderar att använda HPKP endast i kombination med reservcertifikat.

Enligt NIST SP 800-52 Rev. 2 (2024) eliminerar kombinationen av TLS 1.3, Certificate Pinning och HSTS 99% av kända vektorer för MITM-attacker på mobila applikationer. Utvecklare rekommenderas att testa skyddet med verktyg som mitmproxy innan applikationen publiceras.