Mga Atake ng MITM sa Mobile Apps — ano ito, mga uri at proteksyon mula sa pagharang

Ano ang atake ng MITM?

Man-in-the-Middle (MITM) — isang uri ng cyber atake kung saan ang isang cybercriminal ay palihim na pumapasok sa channel ng komunikasyon sa pagitan ng dalawang partido. Maaaring harangin, basahin at baguhin ng cybercriminal ang ipinapadalang data, habang nananatiling hindi nakikita para sa parehong partido.

Sa mobile apps, ang mga atake ng MITM ay partikular na mapanganib dahil ang mga device ay patuloy na kumokonekta sa iba't ibang network — bahay, opisina, pampublikong Wi-Fi sa mga cafe at paliparan. Ang bawat paglipat ng network ay potensyal na lumilikha ng pagkakataon para sa atake. Ayon sa Verizon Mobile Security Index (2025), 43% ng mga organisasyon ay kahit isang beses nakatagpo ng mga atake ng MITM sa mga corporate mobile device.

Ang pangunahing panganib ng MITM — pagiging lihim: ang user at server ay hindi nakakatanggap ng mga senyales tungkol sa pagharang. Ang session ay mukhang normal, ang data ay ipinapadala, walang mga error sa certificate (kung gumagamit ang attacker ng sarili niyang certificate). Ang pagtuklas ng atake ay posible lamang sa antas ng network infrastructure o sa mga espesyal na tool.

Kailangang maunawaan ng developer ang mga mekanismo ng mga atake ng MITM upang idisenyo ang proteksyon sa antas ng app, hindi lamang umasa sa seguridad ng transport layer.

Mga pangunahing uri ng atake ng MITM

Ang klasipikasyon ng mga atake ng MITM ay may kasamang ilang uri na nagkakaiba sa paraan ng pagpasok sa channel ng komunikasyon. Sa mobile development, tatlong uri ang pinaka-kaugnay.

ARP Spoofing sa lokal na network

ARP Spoofing — isang teknik kung saan ang attacker ay nagpapadala ng mga pekeng ARP packet sa lokal na network, na nag-uugnay ng kanyang MAC address sa IP address ng gateway. Pagkatapos nito, lahat ng trapiko ng biktima ay idinidirekta sa pamamagitan ng device ng attacker, na nagpapasa nito sa gateway, nananatiling hindi nakikita.

Para sa pagsasagawa ng atake, sapat na ang mga tool tulad ng Ettercap o BetterCAP, na nag-automate ng ARP-spoofing. Ang atake ay posible lamang sa loob ng isang subnet, kaya ang mga user ng pampublikong Wi-Fi network ay pinaka-mahina. Ang mga modernong network na may dynamic na ARP inspection (DAI) sa mga managed switch ay humaharang sa uri ng atake na ito.

Ang proteksyon sa antas ng app mula sa ARP Spoofing ay imposible — ito ay problema ng network infrastructure. Gayunpaman, maaaring matukoy ng app ang mga anomalya sa network connection gamit ang mga library tulad ng TrustKit para sa iOS o Network Security Config para sa Android.

DNS Spoofing at pagharang ng trapiko

DNS Spoofing (o DNS Cache Poisoning) — pagpeke ng mga DNS record sa daan mula sa client patungo sa DNS server. Hinaharangan ng attacker ang DNS request ng app at nagbabalik ng pekeng IP address, na nagdidirekta ng trapiko sa kanyang sariling server sa halip na sa lehitimong server.

Ang atake ay partikular na epektibo sa mga pampublikong network kung saan ang DNS server ay awtomatikong itinatalaga sa pamamagitan ng DHCP. Maaaring i-configure ng attacker ang kanyang sariling DNS server na nagbabalik ng mga pekeng IP address para sa mga target na domain. Nakikita ng user ang lehitimong URL sa browser, ngunit kumokonekta sa server ng attacker.

Ang proteksyon mula sa DNS Spoofing sa panig ng app ay naisasagawa sa pamamagitan ng DNS-over-HTTPS (DoH) o DNS-over-TLS (DoT), na nag-e-encrypt ng mga DNS request. Sinusuportahan ng Android 9+ at iOS 14+ ang system DoH, maaaring malinaw na i-activate ng app ang opsyong ito.

SSL Stripping — pag-iwas sa HTTPS

SSL Stripping — isang atake kung saan binababa ng attacker ang secure na HTTPS na koneksyon sa hindi secure na HTTP. Ginagamit ng teknik ang katotohanan na maraming user ang manu-manong nagta-type ng example.com sa halip na https://example.com, at ang unang koneksyon ay itinatag sa pamamagitan ng HTTP.

Ang mga tool tulad ng sslstrip (Moxie Marlinspike, 2009) at bettercap ay awtomatikong humaharang ng mga HTTP request, nagtatatag ng HTTPS na koneksyon sa server sa kanilang sariling pangalan, at nagpapadala ng decrypted na trapiko sa client sa pamamagitan ng HTTP. Ang browser ay hindi nagpapakita ng icon ng kandado — hindi alam ng user na ang koneksyon ay hindi secure.

Ang modernong proteksyon — HTTP Strict Transport Security (HSTS): ang server ay nagpapaalam sa browser na ang lahat ng hinaharap na koneksyon ay dapat sa pamamagitan lamang ng HTTPS. Ang HSTS Preload List ay nagbibigay ng karagdagang proteksyon laban sa unang atake, ngunit nangangailangan ng paunang pagpaparehistro ng domain.

Paano gumagana ang atake ng MITM sa mobile apps

Ang isang tipikal na atake ng MITM sa mobile app ay dumadaan sa apat na yugto. Bawat yugto ay gumagamit ng iba't ibang kahinaan, at para sa kumpletong proteksyon, lahat ng vectors ay dapat harangin.

Unang yugto — pagpasok: ang attacker ay nasa daan ng trapiko sa pagitan ng device at server. Ito ay maaaring ARP Spoofing sa lokal na network, pekeng Wi-Fi point (Evil Twin), o kompromiso ng DNS server ng provider. Ang mga mobile device ay partikular na mahina kapag awtomatikong kumokonekta sa mga bukas na network.

Ikalawang yugto — pagharang: pagkatapos ng pagpasok, sinimulan ng attacker na basahin ang lahat ng packet na ipinagpapalit ng app at server. Sa yugtong ito, nangongolekta siya ng metadata: URL ng mga request, laki ng packet, cookies, headers. Kahit na ang data ay naka-encrypt, ang metadata ay maaaring magbunyag ng istraktura ng app at business logic.

Ikatlong yugto — decryption (kung ang trapiko ay naka-encrypt): ang attacker ay nagtatatag ng dalawang TLS na koneksyon — isa sa server (gamit ang pekeng certificate), isa sa client. Itinuturing ng app na secure ang koneksyon, ngunit nakikita ng attacker ang lahat ng data sa malinaw na anyo. Kung walang Certificate Pinning, ito ay gumagana para sa anumang certificate na naka-install sa system store.

Ikaapat na yugto — pagbabago at exfiltration: ang attacker ay hindi lamang makakabasa, kundi makakapagbago rin ng ipinapadalang data. Sa financial apps, ito ay maaaring mangahulugan ng pagbabago ng account number ng receiver, sa mga API request — pagbabago ng mga parameter ng awtorisasyon. Ang iOS at Android ay nagrerekomenda ng implementasyon ng integrity check ng mga response sa antas ng app.

Mga halimbawa ng code: proteksyon mula sa pagharang sa Android at iOS

Tingnan natin ang mga praktikal na halimbawa ng proteksyon mula sa mga atake ng MITM gamit ang Certificate Pinning sa Kotlin at Swift. Ang mga halimbawang ito ay humaharang sa pagpapalit ng certificate kahit na may kompromisong system store.

Certificate Pinning sa Android (OkHttp)

OkHttp — ang karaniwang HTTP library para sa Android na sumusuporta sa CertificatePinner. Tukuyin ang SHA-256 hash ng certificate ng iyong server — lahat ng iba pang certificate ay tatanggihan.

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

Sa iOS, gamitin ang URLSessionDelegate para sa manu-manong verification ng certificate ng server. Ihambing ang SecCertificateRef sa lokal na naka-save na kopya.

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

Sinusuportahan ng Android ang declarative na proteksyon sa pamamagitan ng XML file na network_security_config.xml, na humaharang sa trapiko sa antas ng OS nang walang pagsusulat ng code.

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

Mga paraan ng proteksyon ng mobile apps mula sa MITM

Ang komprehensibong proteksyon mula sa mga atake ng MITM ay may kasamang mga hakbang sa antas ng app, server, at network infrastructure. Sa ibaba ay ang mga pangunahing rekomendasyon para sa Android at iOS.

Gamitin ang Certificate Pinning — pagtali ng certificate ng server sa code ng app. Hindi tulad ng karaniwang TLS verification na nagtitiwala sa anumang certificate mula sa system store, sinusuri ng Certificate Pinning ang isang partikular na certificate o ang pampublikong key nito. Ang OkHttp sa Android at TrustKit sa iOS ay nagbibigay ng mga handa nang implementasyon ng mekanismong ito.

Pilitin ang HTTPS at HSTS: lahat ng network request ay dapat dumaan sa HTTPS, at ang server ay dapat magbalik ng Strict-Transport-Security header. Para sa Android, idagdag ang android:usesCleartextTraffic="false" sa manifest — ito ay magbabawal ng HTTP na koneksyon sa antas ng OS. Ang iOS ay default na nagbabawal ng HTTP mula noong iOS 9 sa pamamagitan ng App Transport Security (ATS).

Ipatupad ang integrity check ng mga response: lagdaan ang mga response ng server ng digital signature na sinusuri ng app. Kahit na harangin ng attacker ang HTTPS trapiko (sa pamamagitan ng proxy na may muling pag-install ng certificate), hindi niya magagawang pekein ang lagda nang walang private key ng server. Gamitin ang JWT na may RS256 o HMAC na mga lagda para sa mga kritikal na operasyon.

Sa panig ng server, i-activate ang HTTP Public Key Pinning (HPKP) — isang direktiba na nagsasabi sa browser o app kung aling certificate ang itinuturing na wasto para sa isang partikular na domain. Gayunpaman, ang HPKP ay nangangailangan ng pag-iingat: ang maling configuration ay maaaring humarang sa access sa app para sa mahabang panahon. Inirerekomenda ng Google ang paggamit ng HPKP lamang sa kumbinasyon ng mga backup na certificate.

Ayon sa NIST SP 800-52 Rev. 2 (2024), ang kumbinasyon ng TLS 1.3, Certificate Pinning at HSTS ay nag-aalis ng 99% ng mga kilalang vectors ng mga atake ng MITM sa mobile apps. Ang mga developer ay inirerekomenda na subukan ang proteksyon gamit ang mga tool tulad ng mitmproxy bago ilathala ang app.