MITM-támadások mobilalkalmazásokban — mi ez, típusok és védelem a lehallgatás ellen

Mi az MITM-támadás?

Man-in-the-Middle (MITM) — egy olyan kibertámadás, amely során a kiberbűnöző titokban behatol a két fél közötti kommunikációs csatornába. A kiberbűnöző lehallgathatja, elolvashatja és módosíthatja a továbbított adatokat, miközben mindkét fél számára láthatatlan marad.

A mobilalkalmazásokban az MITM-támadások különösen veszélyesek, mivel az eszközök folyamatosan különböző hálózatokhoz csatlakoznak — otthoni, irodai, nyilvános Wi-Fi-hez kávézókban és repülőtereken. Minden hálózatváltás potenciálisan támadási ablakot hoz létre. A Verizon Mobile Security Index (2025) szerint a szervezetek 43%-a legalább egyszer találkozott MITM-támadásokkal a vállalati mobileszközökön.

Az MITM fő veszélye — a rejtettség: a felhasználó és a szerver nem kap jeleket a lehallgatásról. A munkamenet normálisnak tűnik, az adatok továbbításra kerülnek, nincsenek tanúsítványhibák (ha a támadó saját tanúsítványt használ). A támadás észlelése csak a hálózati infrastruktúra szintjén vagy speciális eszközökkel lehetséges.

A fejlesztőnek meg kell értenie az MITM-támadások mechanizmusait, hogy az alkalmazás szintjén tervezze meg a védelmet, ne csak a szállítási réteg biztonságára támaszkodjon.

Az MITM-támadások fő típusai

Az MITM-támadások osztályozása több típust foglal magában, amelyek a kommunikációs csatornába való behatolás módjában különböznek. A mobilfejlesztésben három típus a legrelevánsabb.

ARP Spoofing a helyi hálózatban

ARP Spoofing — egy olyan technika, amely során a támadó hamis ARP-csomagokat küld a helyi hálózatba, összekapcsolva saját MAC-címét az átjáró IP-címével. Ezt követően az áldozat teljes forgalma a támadó eszközén keresztül irányítódik, aki továbbítja azt az átjárónak, miközben láthatatlan marad.

A támadás végrehajtásához elegendőek az olyan eszközök, mint az Ettercap vagy a BetterCAP, amelyek automatizálják az ARP-spoofingot. A támadás csak egy alhálózaton belül lehetséges, ezért a nyilvános Wi-Fi-hálózatok felhasználói a legsérülékenyebbek. A felügyelt kapcsolókon dinamikus ARP-ellenőrzéssel (DAI) rendelkező modern hálózatok blokkolják ezt a támadástípust.

Az ARP Spoofing elleni védelem alkalmazásszinten lehetetlen — ez a hálózati infrastruktúra problémája. Az alkalmazás azonban észlelheti a hálózati kapcsolat anomáliáit olyan könyvtárak segítségével, mint a TrustKit iOS-re vagy a Network Security Config Androidra.

DNS Spoofing és forgalomlehallgatás

DNS Spoofing (vagy DNS Cache Poisoning) — a DNS-rekordok hamisítása a klienstől a DNS-szerverig vezető úton. A támadó lehallgatja az alkalmazás DNS-kérését, és hamis IP-címet ad vissza, a forgalmat a legitim szerver helyett a saját szerverére irányítva.

A támadás különösen hatékony a nyilvános hálózatokban, ahol a DNS-szerver automatikusan DHCP-n keresztül kerül kiosztásra. A támadó konfigurálhatja saját DNS-szerverét, amely hamis IP-címeket ad vissza a céldomainekhez. A felhasználó legitim URL-t lát a böngészőben, de a támadó szerveréhez csatlakozik.

A DNS Spoofing elleni védelem az alkalmazás oldalán a DNS-kéréseket titkosító DNS-over-HTTPS (DoH) vagy DNS-over-TLS (DoT) segítségével valósítható meg. Az Android 9+ és iOS 14+ támogatja a rendszer szintű DoH-t, az alkalmazás explicit módon bekapcsolhatja ezt az opciót.

SSL Stripping — a HTTPS megkerülése

SSL Stripping — egy olyan támadás, amely során a támadó a védett HTTPS-kapcsolatot nem biztonságos HTTP-vé minősíti le. A technika kihasználja, hogy sok felhasználó manuálisan írja be a example.com címet a https://example.com helyett, és az első kapcsolat HTTP-n keresztül jön létre.

Az olyan eszközök, mint az sslstrip (Moxie Marlinspike, 2009) és a bettercap automatikusan lehallgatják a HTTP-kéréseket, saját nevükben HTTPS-kapcsolatot hoznak létre a szerverrel, és a visszafejtett forgalmat HTTP-n keresztül továbbítják a kliensnek. A böngésző nem jeleníti meg a lakat ikont — a felhasználó nem tudja, hogy a kapcsolat nem biztonságos.

Modern védelem — HTTP Strict Transport Security (HSTS): a szerver tájékoztatja a böngészőt, hogy minden jövőbeli kapcsolatnak csak HTTPS-en keresztül szabad történnie. A HSTS Preload List további védelmet nyújt az első támadás ellen, de a domain előzetes regisztrációját igényli.

Hogyan működik az MITM-támadás a mobilalkalmazásokban

Egy tipikus MITM-támadás egy mobilalkalmazás ellen négy szakaszon megy keresztül. Minden szakasz különböző sebezhetőségeket használ ki, és a teljes védelemhez minden vektort blokkolni kell.

Első szakasz — behatolás: a támadó az eszköz és a szerver közötti forgalom útjába kerül. Ez lehet ARP Spoofing a helyi hálózatban, hamis Wi-Fi-pont (Evil Twin) vagy a szolgáltató DNS-szerverének kompromittálása. A mobileszközök különösen sérülékenyek a nyílt hálózatokhoz való automatikus csatlakozáskor.

Második szakasz — lehallgatás: a behatolás után a támadó elkezdi olvasni az alkalmazás és a szerver által váltott összes csomagot. Ebben a szakaszban metaadatokat gyűjt: a kérések URL-jeit, csomagméreteket, sütiket, fejléceket. Még ha az adatok titkosítottak is, a metaadatok felfedhetik az alkalmazás szerkezetét és üzleti logikáját.

Harmadik szakasz — visszafejtés (ha a forgalom titkosított): a támadó két TLS-kapcsolatot hoz létre — egyet a szerverrel (hamis tanúsítványt használva), egyet a klienssel. Az alkalmazás biztonságosnak tekinti a kapcsolatot, de a támadó minden adatot nyílt formában lát. Certificate Pinning nélkül ez bármely, a rendszertárolóba telepített tanúsítvány esetén működik.

Negyedik szakasz — módosítás és adatszivárgás: a támadó nemcsak olvasni, hanem módosítani is tudja a továbbított adatokat. Pénzügyi alkalmazásokban ez a kedvezményezett számlaszámának megváltoztatását, API-kérésekben az engedélyezési paraméterek módosítását jelentheti. Az iOS és Android javasolja a válaszok integritásának ellenőrzését alkalmazásszinten.

Kódpéldák: védelem a lehallgatás ellen Androidon és iOS-en

Tekintsük át a gyakorlati példákat az MITM-támadások elleni védelemre Certificate Pinning használatával Kotlin és Swift nyelven. Ezek a példák blokkolják a tanúsítvány helyettesítését még egy kompromittált rendszertároló esetén is.

Certificate Pinning Androidon (OkHttp)

Az OkHttp — a szabványos HTTP-könyvtár Androidhoz, amely támogatja a CertificatePinner-t. Adja meg a szerver tanúsítványának SHA-256 hash-értékét — minden más tanúsítvány elutasításra kerül.

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

iOS-en használja a URLSessionDelegate delegate-et a szerver tanúsítványának manuális ellenőrzéséhez. Hasonlítsa össze a SecCertificateRef-et a helyileg mentett másolattal.

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 Androidon

Az Android deklaratív védelmet támogat a network_security_config.xml XML-fájlon keresztül, amely kódírás nélkül blokkolja a forgalmat az operációs rendszer szintjén.

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

Mobilalkalmazások védelmének módszerei az MITM ellen

Az MITM-támadások elleni átfogó védelem intézkedéseket foglal magában az alkalmazás, a szerver és a hálózati infrastruktúra szintjén. Az alábbiakban az Android és iOS fő ajánlásai találhatók.

Használja a Certificate Pinning-et — a szervertanúsítvány rögzítését az alkalmazás kódjában. Ellentétben a szabványos TLS-ellenőrzéssel, amely bármely, a rendszertárolóból származó tanúsítványnak megbízik, a Certificate Pinning egy adott tanúsítványt vagy annak nyilvános kulcsát ellenőrzi. Az OkHttp Androidon és a TrustKit iOS-en kész implementációkat biztosítanak ehhez a mechanizmushoz.

Kényszerítse ki a HTTPS-t és a HSTS-t: minden hálózati kérésnek HTTPS-en kell mennie, és a szervernek vissza kell adnia a Strict-Transport-Security fejlécet. Android esetén adja hozzá a android:usesCleartextTraffic="false" elemet a manifesztumhoz — ez letiltja a HTTP-kapcsolatokat az operációs rendszer szintjén. Az iOS alapértelmezés szerint tiltja a HTTP-t az iOS 9 óta az App Transport Security (ATS) segítségével.

Valósítsa meg a válaszok integritásának ellenőrzését: írja alá a szerver válaszait digitális aláírással, amelyet az alkalmazás ellenőriz. Még ha a támadó le is hallgatja a HTTPS-forgalmat (proxyn keresztül a tanúsítvány újratelepítésével), nem tudja meghamisítani az aláírást a szerver privát kulcsa nélkül. Használjon JWT-t RS256-tal vagy HMAC-aláírásokat a kritikus műveletekhez.

A szerver oldalán kapcsolja be a HTTP Public Key Pinning (HPKP) funkciót — egy olyan direktívát, amely megmondja a böngészőnek vagy az alkalmazásnak, hogy melyik tanúsítványt tekintse érvényesnek egy adott domainhez. A HPKP azonban óvatosságot igényel: a helytelen konfiguráció hosszú időre blokkolhatja az alkalmazáshoz való hozzáférést. A Google azt javasolja, hogy a HPKP-t csak tartalék tanúsítványokkal kombinálva használja.

A NIST SP 800-52 Rev. 2 (2024) szerint a TLS 1.3, a Certificate Pinning és a HSTS kombinációja megszünteti az ismert MITM-támadási vektorok 99%-át a mobilalkalmazásokban. A fejlesztőknek ajánlott a védelmet olyan eszközökkel tesztelni, mint a mitmproxy, mielőtt közzéteszik az alkalmazást.