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 пре објављивања апликације.