MITM-атаки в мобільних додатках — що це, види та захист від перехоплення

Що таке MITM-атака?

Man-in-the-Middle (MITM) — тип кібератаки, при якій зловмисник таємно вбудовується в канал зв’язку між двома сторонами. Зловмисник може перехоплювати, читати та модифікувати передані дані, залишаючись невидимим для обох сторін.

У мобільних додатках MITM-атаки особливо небезпечні, оскільки пристрої постійно підключаються до різних мереж — домашніх, офісних, публічних Wi-Fi у кафе та аеропортах. Кожне перемикання мережі потенційно створює вікно для атаки. За даними Verizon Mobile Security Index (2025), 43% організацій хоча б раз стикалися з MITM-атаками на корпоративні мобільні пристрої.

Головна небезпека MITM — скритність: користувач і сервер не отримують сигналів про перехоплення. Сесія виглядає нормальною, дані передаються, помилок сертифікатів немає (якщо зловмисник використовує власний сертифікат). Виявити атаку можна лише на рівні мережевої інфраструктури або за допомогою спеціалізованих інструментів.

Розробнику необхідно розуміти механізми MITM-атак, щоб проектувати захист на рівні додатка, а не покладатися виключно на безпеку транспортного рівня.

Основні види MITM-атак

Класифікація MITM-атак включає кілька типів, які різняться за методом впровадження в канал зв’язку. У мобільній розробці найбільш актуальні три види.

ARP Spoofing у локальній мережі

ARP Spoofing — техніка, при якій зловмисник надсилає підроблені ARP-пакети в локальну мережу, пов’язуючи свою MAC-адресу з IP-адресою шлюзу. Після цього весь трафік жертви направляється через пристрій зловмисника, який пересилає його шлюзу, залишаючись невидимим.

Для проведення атаки достатньо інструментів на кшталт Ettercap або BetterCAP, які автоматизують ARP-спуфінг. Атака можлива лише в межах однієї підмережі, тому найбільш уразливі користувачі публічних Wi-Fi-мереж. Сучасні мережі з динамічною ARP-інспекцією (DAI) на керованих комутаторах блокують цей тип атаки.

Захист на рівні додатка від ARP Spoofing неможливий — це проблема мережевої інфраструктури. Однак додаток може детектувати аномалії в мережевому підключенні за допомогою бібліотек на кшталт TrustKit для iOS або Network Security Config для Android.

DNS Spoofing та перехоплення трафіку

DNS Spoofing (або отруєння кешу DNS) — підміна DNS-записів на шляху від клієнта до DNS-сервера. Зловмисник перехоплює DNS-запит додатка і повертає підроблену IP-адресу, направляючи трафік на свій сервер замість легітимного.

Атака особливо ефективна в публічних мережах, де DNS-сервер призначається автоматично через DHCP. Зловмисник може налаштувати власний DNS-сервер, який повертає підставні IP-адреси для цільових доменів. Користувач бачить легітимний URL у браузері, але з’єднується з сервером зловмисника.

Захист від DNS Spoofing на стороні додатка реалізується через DNS-over-HTTPS (DoH) або DNS-over-TLS (DoT), які шифрують DNS-запити. Android 9+ та iOS 14+ підтримують системний DoH, додаток може явно включити цю опцію.

SSL Stripping — обхід HTTPS

SSL Stripping — атака, при якій зловмисник знижує захищене HTTPS-з’єднання до незахищеного HTTP. Техніка експлуатує те, що багато користувачів вручну вводять example.com замість https://example.com, і перше з’єднання встановлюється через HTTP.

Інструменти на кшталт sslstrip (Moxie Marlinspike, 2009) та bettercap автоматично перехоплюють HTTP-запити, встановлюють HTTPS-з’єднання з сервером від свого імені та передають розшифрований трафік клієнту через HTTP. Браузер не показує значок замка — користувач не знає, що з’єднання не захищене.

Сучасний захист — HTTP Strict Transport Security (HSTS): сервер повідомляє браузеру, що всі майбутні з’єднання повинні бути тільки через HTTPS. HSTS Preload List додатково захищає від першої атаки, але вимагає попередньої реєстрації домену.

Як працює MITM-атака в мобільних додатках

Типова MITM-атака на мобільний додаток проходить чотири етапи. Кожен етап використовує різні вразливості, і для повного захисту потрібно перекривати всі вектори.

Перший етап — впровадження: зловмисник опиняється на шляху трафіку між пристроєм і сервером. Це може бути ARP Spoofing у локальній мережі, підроблена точка Wi-Fi (Evil Twin) або компрометація DNS-сервера провайдера. Мобільні пристрої особливо вразливі при автоматичному підключенні до відкритих мереж.

Другий етап — перехоплення: після впровадження зловмисник починає читати всі пакети, якими обмінюються додаток і сервер. На цьому етапі він збирає метадані: URL запитів, розмір пакетів, cookies, заголовки. Навіть якщо дані зашифровані, метадані можуть розкрити структуру додатка та бізнес-логіку.

Третій етап — дешифрування (якщо трафік зашифрований): зловмисник встановлює два TLS-з’єднання — одне з сервером (використовуючи підставний сертифікат), інше з клієнтом. Додаток вважає підключення безпечним, але зловмисник бачить усі дані у відкритому вигляді. Без Certificate Pinning це працює для будь-якого сертифіката, встановленого в системному сховищі.

Четвертий етап — модифікація та ексфільтрація: зловмисник може не тільки читати, але й змінювати передані дані. У фінансових додатках це може означати підміну номера рахунку отримувача, в API-запитах — зміну параметрів авторизації. iOS та Android рекомендують реалізовувати перевірку цілісності відповідей на рівні додатка.

Приклади коду: захист від перехоплення на Android та iOS

Розглянемо практичні приклади захисту від MITM-атак з використанням Certificate Pinning на Kotlin та Swift. Ці приклади блокують підміну сертифіката навіть за наявності скомпрометованого системного сховища.

Certificate Pinning на Android (OkHttp)

OkHttp — стандартна HTTP-бібліотека для Android, яка підтримує CertificatePinner. Вкажіть SHA-256 хеш сертифіката вашого сервера — будь-які інші сертифікати будуть відхилені.

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

На iOS використовуйте URLSessionDelegate для перевірки сертифіката сервера вручну. Порівнюйте SecCertificateRef з локально збереженою копією.

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 на Android

Android підтримує декларативний захист через XML-файл network_security_config.xml, який блокує трафік на рівні ОС без написання коду.

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

Методи захисту мобільних додатків від MITM

Комплексний захист від MITM-атак включає заходи на рівні додатка, сервера та мережевої інфраструктури. Нижче наведені основні рекомендації для Android та iOS.

Використовуйте Certificate Pinning — прив’язку сертифіката сервера в коді додатка. На відміну від стандартної TLS-перевірки, яка довіряє будь-якому сертифікату з системного сховища, Certificate Pinning перевіряє конкретний сертифікат або його публічний ключ. OkHttp на Android та TrustKit на iOS надають готові реалізації цього механізму.

Примусово використовуйте HTTPS та HSTS: всі мережеві запити повинні йти через HTTPS, а сервер повинен повертати заголовок Strict-Transport-Security. Для Android додайте android:usesCleartextTraffic="false" у маніфест — це заборонить HTTP-з’єднання на рівні ОС. iOS за замовчуванням забороняє HTTP з iOS 9 через App Transport Security (ATS).

Реалізуйте перевірку цілісності відповідей: підписуйте відповіді сервера цифровим підписом, який перевіряє додаток. Навіть якщо зловмисник перехопить HTTPS-трафік (через проксі з перевстановленням сертифіката), він не зможе підробити підпис без приватного ключа сервера. Використовуйте JWT з RS256 або HMAC-підписами для критичних операцій.

На серверній стороні увімкніть HTTP Public Key Pinning (HPKP) — директива, яка вказує браузеру або додатку, який сертифікат вважати валідним для даного домену. Однак HPKP вимагає обережності: неправильне налаштування може заблокувати доступ до додатка на тривалий термін. Google рекомендує використовувати HPKP тільки в комбінації з резервними сертифікатами.

За даними NIST SP 800-52 Rev. 2 (2024), комбінація TLS 1.3, Certificate Pinning та HSTS усуває 99% відомих векторів MITM-атак на мобільні додатки. Розробникам рекомендується протестувати захист за допомогою інструментів на кшталт mitmproxy перед публікацією додатка.