Ataki MITM w aplikacjach mobilnych — czym są, rodzaje i ochrona przed przechwyceniem

Czym jest atak MITM?

Man-in-the-Middle (MITM) to rodzaj cyberataku, w którym cyberprzestępca potajemnie włącza się w kanał komunikacyjny między dwiema stronami. Cyberprzestępca może przechwytywać, odczytywać i modyfikować przesyłane dane, pozostając niewidocznym dla obu stron.

W aplikacjach mobilnych ataki MITM są szczególnie niebezpieczne, ponieważ urządzenia stale łączą się z różnymi sieciami — domowymi, biurowymi, publicznymi Wi-Fi w kawiarniach i na lotniskach. Każde przełączenie sieci potencjalnie tworzy okno do ataku. Według Verizon Mobile Security Index (2025), 43% organizacji przynajmniej raz doświadczyło ataków MITM na firmowe urządzenia mobilne.

Główne zagrożenie MITM — ukrytość: użytkownik i serwer nie otrzymują sygnałów o przechwyceniu. Sesja wygląda normalnie, dane są przesyłane, nie ma błędów certyfikatów (jeśli atakujący używa własnego certyfikatu). Wykrycie ataku możliwe jest tylko na poziomie infrastruktury sieciowej lub za pomocą specjalistycznych narzędzi.

Deweloper musi rozumieć mechanizmy ataków MITM, aby projektować ochronę na poziomie aplikacji, a nie polegać wyłącznie na bezpieczeństwie warstwy transportowej.

Główne rodzaje ataków MITM

Klasyfikacja ataków MITM obejmuje kilka typów różniących się metodą włączenia w kanał komunikacyjny. W mobilnym developmentcie najbardziej aktualne są trzy rodzaje.

ARP Spoofing w sieci lokalnej

ARP Spoofing to technika, w której cyberprzestępca wysyła fałszywe pakiety ARP do sieci lokalnej, łącząc swój adres MAC z adresem IP bramy. Po tym cały ruch ofiary kierowany jest przez urządzenie atakującego, który przekazuje go do bramy, pozostając niewidocznym.

Do przeprowadzenia ataku wystarczą narzędzia takie jak Ettercap lub BetterCAP, które automatyzują ARP-spoofing. Atak jest możliwy tylko w obrębie jednej podsieci, dlatego najbardziej narażeni są użytkownicy publicznych sieci Wi-Fi. Nowoczesne sieci z dynamiczną inspekcją ARP (DAI) na zarządzanych przełącznikach blokują ten typ ataku.

Ochrona na poziomie aplikacji przed ARP Spoofing jest niemożliwa — to problem infrastruktury sieciowej. Jednak aplikacja może wykrywać anomalie w połączeniu sieciowym za pomocą bibliotek takich jak TrustKit dla iOS lub Network Security Config dla Android.

DNS Spoofing i przechwycenie ruchu

DNS Spoofing (lub DNS Cache Poisoning) — podmiana rekordów DNS na drodze od klienta do serwera DNS. Cyberprzestępca przechwytuje zapytanie DNS aplikacji i zwraca fałszywy adres IP, kierując ruch na swój serwer zamiast na legalny.

Atak jest szczególnie skuteczny w sieciach publicznych, gdzie serwer DNS jest przypisywany automatycznie przez DHCP. Cyberprzestępca może skonfigurować własny serwer DNS, który zwraca podstawione adresy IP dla docelowych domen. Użytkownik widzi legalny URL w przeglądarce, ale łączy się z serwerem atakującego.

Ochrona przed DNS Spoofing po stronie aplikacji realizowana jest przez DNS-over-HTTPS (DoH) lub DNS-over-TLS (DoT), które szyfrują zapytania DNS. Android 9+ i iOS 14+ obsługują systemowy DoH, aplikacja może jawnie włączyć tę opcję.

SSL Stripping — obchodzenie HTTPS

SSL Stripping to atak, w którym cyberprzestępca obniża bezpieczne połączenie HTTPS do niezabezpieczonego HTTP. Technika wykorzystuje fakt, że wielu użytkowników ręcznie wpisuje example.com zamiast https://example.com, a pierwsze połączenie nawiązywane jest przez HTTP.

Narzędzia takie jak sslstrip (Moxie Marlinspike, 2009) i bettercap automatycznie przechwytują żądania HTTP, nawiązują połączenie HTTPS z serwerem we własnym imieniu i przekazują odszyfrowany ruch klientowi przez HTTP. Przeglądarka nie pokazuje ikony kłódki — użytkownik nie wie, że połączenie nie jest bezpieczne.

Nowoczesna ochrona — HTTP Strict Transport Security (HSTS): serwer informuje przeglądarkę, że wszystkie przyszłe połączenia muszą być tylko przez HTTPS. HSTS Preload List dodatkowo chroni przed pierwszym atakiem, ale wymaga wcześniejszej rejestracji domeny.

Jak działa atak MITM w aplikacjach mobilnych

Typowy atak MITM na aplikację mobilną przechodzi cztery etapy. Każdy etap wykorzystuje różne podatności, a do pełnej ochrony wymagane jest zablokowanie wszystkich wektorów.

Pierwszy etap — włączenie: cyberprzestępca znajduje się na drodze ruchu między urządzeniem a serwerem. Może to być ARP Spoofing w sieci lokalnej, fałszywy punkt Wi-Fi (Evil Twin) lub kompromitacja serwera DNS dostawcy. Urządzenia mobilne są szczególnie narażone przy automatycznym łączeniu się z otwartymi sieciami.

Drugi etap — przechwycenie: po włączeniu cyberprzestępca zaczyna odczytywać wszystkie pakiety, którymi wymieniają się aplikacja i serwer. Na tym etapie zbiera metadane: URL żądań, rozmiar pakietów, cookies, nagłówki. Nawet jeśli dane są szyfrowane, metadane mogą ujawnić strukturę aplikacji i logikę biznesową.

Trzeci etap — deszyfrowanie (jeśli ruch jest szyfrowany): cyberprzestępca nawiązuje dwa połączenia TLS — jedno z serwerem (używając podstawionego certyfikatu), drugie z klientem. Aplikacja uważa połączenie za bezpieczne, ale atakujący widzi wszystkie dane w otwartej postaci. Bez Certificate Pinning działa to dla każdego certyfikatu zainstalowanego w magazynie systemowym.

Czwarty etap — modyfikacja i eksfiltracja: cyberprzestępca może nie tylko czytać, ale także modyfikować przesyłane dane. W aplikacjach finansowych może to oznaczać podmianę numeru konta odbiorcy, w żądaniach API — zmianę parametrów autoryzacji. iOS i Android zalecają implementację sprawdzania integralności odpowiedzi na poziomie aplikacji.

Przykłady kodu: ochrona przed przechwyceniem na Android i iOS

Rozważmy praktyczne przykłady ochrony przed atakami MITM z użyciem Certificate Pinning w Kotlin i Swift. Te przykłady blokują podmianę certyfikatu nawet przy skompromitowanym magazynie systemowym.

Certificate Pinning na Android (OkHttp)

OkHttp — standardowa biblioteka HTTP dla Android, która obsługuje CertificatePinner. Podaj skrót SHA-256 certyfikatu swojego serwera — wszelkie inne certyfikaty zostaną odrzucone.

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

Na iOS użyj URLSessionDelegate do ręcznego sprawdzania certyfikatu serwera. Porównaj SecCertificateRef z lokalnie zapisaną kopią.

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

Android obsługuje deklaratywną ochronę przez plik XML network_security_config.xml, który blokuje ruch na poziomie systemu operacyjnego bez pisania kodu.

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

Metody ochrony aplikacji mobilnych przed MITM

Kompleksowa ochrona przed atakami MITM obejmuje środki na poziomie aplikacji, serwera i infrastruktury sieciowej. Poniżej przedstawiono główne zalecenia dla Android i iOS.

Używaj Certificate Pinning — przypięcie certyfikatu serwera w kodzie aplikacji. W przeciwieństwie do standardowej weryfikacji TLS, która ufa każdemu certyfikatowi z magazynu systemowego, Certificate Pinning sprawdza konkretny certyfikat lub jego klucz publiczny. OkHttp na Android i TrustKit na iOS dostarczają gotowych implementacji tego mechanizmu.

Wymuszaj HTTPS i HSTS: wszystkie żądania sieciowe powinny iść przez HTTPS, a serwer powinien zwracać nagłówek Strict-Transport-Security. Dla Android dodaj android:usesCleartextTraffic="false" do manifestu — to zabroni połączeń HTTP na poziomie systemu operacyjnego. iOS domyślnie zabrania HTTP od iOS 9 poprzez App Transport Security (ATS).

Zaimplementuj sprawdzanie integralności odpowiedzi: podpisuj odpowiedzi serwera podpisem cyfrowym, który weryfikuje aplikacja. Nawet jeśli cyberprzestępca przechwyci ruch HTTPS (przez proxy z ponowną instalacją certyfikatu), nie będzie mógł sfałszować podpisu bez klucza prywatnego serwera. Używaj JWT z RS256 lub podpisów HMAC do krytycznych operacji.

Po stronie serwera włącz HTTP Public Key Pinning (HPKP) — dyrektywa, która wskazuje przeglądarce lub aplikacji, jaki certyfikat uważać za ważny dla danej domeny. Jednak HPKP wymaga ostrożności: nieprawidłowa konfiguracja może zablokować dostęp do aplikacji na długi czas. Google zaleca używanie HPKP tylko w kombinacji z zapasowymi certyfikatami.

Według NIST SP 800-52 Rev. 2 (2024), kombinacja TLS 1.3, Certificate Pinning i HSTS eliminuje 99% znanych wektorów ataków MITM na aplikacje mobilne. Deweloperzy powinni przetestować ochronę za pomocą narzędzi takich jak mitmproxy przed publikacją aplikacji.