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 Cache Poisoning) — фалшифициране на 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 на заявките, размер на пакетите, бисквитки, заглавки. Дори ако данните са криптирани, метаданните могат да разкрият структурата на приложението и бизнес логиката.

Трети етап — дешифриране (ако трафикът е криптиран): атакуващият установява две 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 преди публикуване на приложението.