การโจมตี 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 spoofing เป็นอัตโนมัติ การโจมตีสามารถทำได้เฉพาะภายในซับเน็ตเดียวเท่านั้น ทำให้ผู้ใช้เครือข่าย Wi-Fi สาธารณะมีความเสี่ยงมากที่สุด เครือข่ายสมัยใหม่ที่มี Dynamic ARP Inspection (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 คำขอ ขนาดแพ็กเก็ต คุกกี้ ส่วนหัว แม้ว่าข้อมูลจะถูกเข้ารหัส ข้อมูลเมตา ก็สามารถเปิดเผยโครงสร้างแอปพลิเคชันและตรรกะทางธุรกิจได้

ขั้นตอนที่สาม — การถอดรหัส (หากการรับส่งข้อมูลถูกเข้ารหัส): ผู้โจมตีสร้างการเชื่อมต่อ 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 รองรับการป้องกันแบบประกาศผ่านไฟล์ 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" ในไฟล์ manifest — สิ่งนี้จะบล็อกการเชื่อมต่อ 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 ก่อนเผยแพร่แอปพลิเคชัน