Tấn công MITM trong ứng dụng di động — định nghĩa, các loại và bảo vệ khỏi đánh chặn

Tấn công MITM là gì?

Man-in-the-Middle (MITM) là một loại tấn công mạng nơi kẻ tấn công bí mật xâm nhập vào kênh liên lạc giữa hai bên. Kẻ tấn công có thể chặn, đọc và sửa đổi dữ liệu được truyền trong khi vẫn vô hình với cả hai bên.

Trong ứng dụng di động, tấn công MITM đặc biệt nguy hiểm vì thiết bị liên tục kết nối với nhiều mạng khác nhau — gia đình, văn phòng, Wi-Fi công cộng tại quán cà phê và sân bay. Mỗi lần chuyển mạng đều có thể tạo ra cơ hội cho tấn công. Theo Verizon Mobile Security Index (2025), 43% tổ chức đã từng gặp phải tấn công MITM trên thiết bị di động doanh nghiệp ít nhất một lần.

Nguy hiểm chính của MITM là tính kín đáo: người dùng và máy chủ không nhận được tín hiệu về việc bị chặn. Phiên trông bình thường, dữ liệu được truyền, không có lỗi chứng chỉ (nếu kẻ tấn công sử dụng chứng chỉ riêng của chúng). Cuộc tấn công chỉ có thể được phát hiện ở cấp độ cơ sở hạ tầng mạng hoặc bằng các công cụ chuyên dụng.

Nhà phát triển cần hiểu các cơ chế của tấn công MITM để thiết kế bảo vệ ở cấp độ ứng dụng, thay vì chỉ dựa vào bảo mật lớp truyền tải.

Các loại tấn công MITM chính

Phân loại tấn công MITM bao gồm một số loại khác nhau về phương pháp xâm nhập vào kênh liên lạc. Trong phát triển di động, ba loại là phổ biến nhất.

ARP Spoofing trên mạng cục bộ

ARP Spoofing là một kỹ thuật nơi kẻ tấn công gửi các gói ARP giả lên mạng cục bộ, liên kết địa chỉ MAC của chúng với địa chỉ IP của gateway. Sau đó, tất cả lưu lượng của nạn nhân được định tuyến qua thiết bị của kẻ tấn công, kẻ này chuyển tiếp nó đến gateway trong khi vẫn vô hình.

Các công cụ như Ettercap hoặc BetterCAP là đủ để thực hiện cuộc tấn công vì chúng tự động hóa ARP spoofing. Cuộc tấn công chỉ khả thi trong một mạng con duy nhất, khiến người dùng mạng Wi-Fi công cộng dễ bị tổn thương nhất. Các mạng hiện đại với Dynamic ARP Inspection (DAI) trên switch được quản lý sẽ chặn loại tấn công này.

Bảo vệ ở cấp độ ứng dụng khỏi ARP Spoofing là không thể — đây là vấn đề của cơ sở hạ tầng mạng. Tuy nhiên, ứng dụng có thể phát hiện các bất thường trong kết nối mạng bằng các thư viện như TrustKit cho iOS hoặc Network Security Config cho Android.

DNS Spoofing và chặn lưu lượng

DNS Spoofing (hoặc đầu độc bộ nhớ đệm DNS) là việc thay thế các bản ghi DNS trên đường từ máy khách đến máy chủ DNS. Kẻ tấn công chặn yêu cầu DNS của ứng dụng và trả về địa chỉ IP giả, chuyển hướng lưu lượng đến máy chủ của chúng thay vì máy chủ hợp pháp.

Cuộc tấn công đặc biệt hiệu quả trong các mạng công cộng nơi máy chủ DNS được chỉ định tự động qua DHCP. Kẻ tấn công có thể thiết lập máy chủ DNS riêng trả về địa chỉ IP giả mạo cho các tên miền mục tiêu. Người dùng thấy URL hợp pháp trong trình duyệt nhưng kết nối với máy chủ của kẻ tấn công.

Bảo vệ khỏi DNS Spoofing ở phía ứng dụng được thực hiện qua DNS-over-HTTPS (DoH) hoặc DNS-over-TLS (DoT), giúp mã hóa các truy vấn DNS. Android 9+ và iOS 14+ hỗ trợ DoH cấp hệ thống và ứng dụng có thể bật tùy chọn này một cách rõ ràng.

SSL Stripping — vượt qua HTTPS

SSL Stripping là một cuộc tấn công nơi kẻ tấn công hạ cấp kết nối HTTPS an toàn xuống HTTP không an toàn. Kỹ thuật này khai thác thực tế rằng nhiều người dùng gõ thủ công example.com thay vì https://example.com và kết nối đầu tiên được thiết lập qua HTTP.

Các công cụ như sslstrip (Moxie Marlinspike, 2009) và bettercap tự động chặn các yêu cầu HTTP, thiết lập kết nối HTTPS với máy chủ thay mặt chúng và chuyển lưu lượng đã giải mã đến máy khách qua HTTP. Trình duyệt không hiển thị biểu tượng ổ khóa — người dùng không biết rằng kết nối không an toàn.

Bảo vệ hiện đại — HTTP Strict Transport Security (HSTS): máy chủ thông báo cho trình duyệt rằng tất cả các kết nối trong tương lai chỉ được sử dụng HTTPS. Danh sách tải trước HSTS cũng bảo vệ khỏi cuộc tấn công đầu tiên nhưng yêu cầu đăng ký tên miền trước.

Cách tấn công MITM hoạt động trong ứng dụng di động

Một cuộc tấn công MITM điển hình vào ứng dụng di động trải qua bốn giai đoạn. Mỗi giai đoạn khai thác các lỗ hổng khác nhau và bảo vệ hoàn chỉnh yêu cầu bao phủ tất cả các vector.

Giai đoạn đầu tiên — xâm nhập: kẻ tấn công đặt mình vào đường đi của lưu lượng giữa thiết bị và máy chủ. Điều này có thể là ARP Spoofing trên mạng cục bộ, điểm truy cập Wi-Fi giả (Evil Twin) hoặc xâm phạm máy chủ DNS của nhà cung cấp. Thiết bị di động đặc biệt dễ bị tổn thương khi tự động kết nối với các mạng mở.

Giai đoạn thứ hai — chặn: sau khi xâm nhập, kẻ tấn công bắt đầu đọc tất cả các gói được trao đổi giữa ứng dụng và máy chủ. Ở giai đoạn này, chúng thu thập siêu dữ liệu: URL yêu cầu, kích thước gói, cookie, tiêu đề. Ngay cả khi dữ liệu được mã hóa, siêu dữ liệu có thể tiết lộ cấu trúc ứng dụng và logic kinh doanh.

Giai đoạn thứ ba — giải mã (nếu lưu lượng được mã hóa): kẻ tấn công thiết lập hai kết nối TLS — một với máy chủ (sử dụng chứng chỉ giả mạo), một với máy khách. Ứng dụng cho rằng kết nối an toàn nhưng kẻ tấn công thấy tất cả dữ liệu dưới dạng văn bản rõ. Nếu không có Certificate Pinning, điều này hoạt động với bất kỳ chứng chỉ nào được cài đặt trong kho hệ thống.

Giai đoạn thứ tư — sửa đổi và trích xuất: kẻ tấn công không chỉ đọc mà còn có thể sửa đổi dữ liệu được truyền. Trong ứng dụng tài chính, điều này có thể có nghĩa là thay đổi số tài khoản người nhận; trong yêu cầu API, sửa đổi tham số ủy quyền. iOS và Android khuyến nghị triển khai kiểm tra tính toàn vẹn phản hồi ở cấp độ ứng dụng.

Ví dụ mã: bảo vệ khỏi đánh chặn trên Android và iOS

Hãy xem các ví dụ thực tế về bảo vệ khỏi tấn công MITM sử dụng Certificate Pinning trong Kotlin và Swift. Các ví dụ này chặn việc thay thế chứng chỉ ngay cả khi kho hệ thống bị xâm phạm.

Certificate Pinning trên Android (OkHttp)

OkHttp là thư viện HTTP tiêu chuẩn cho Android hỗ trợ CertificatePinner. Chỉ định hàm băm SHA-256 của chứng chỉ máy chủ — bất kỳ chứng chỉ nào khác sẽ bị từ chối.

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 trên iOS (URLSession)

Trên iOS, sử dụng URLSessionDelegate để xác minh thủ công chứng chỉ máy chủ. So sánh SecCertificateRef với bản sao được lưu trữ cục bộ.

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 trên Android

Android hỗ trợ bảo vệ khai báo qua tệp network_security_config.xml, chặn lưu lượng ở cấp độ hệ điều hành mà không cần viết mã.

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

Phương pháp bảo vệ ứng dụng di động khỏi MITM

Bảo vệ toàn diện khỏi tấn công MITM bao gồm các biện pháp ở cấp độ ứng dụng, máy chủ và cơ sở hạ tầng mạng. Dưới đây là các khuyến nghị chính cho Android và iOS.

Sử dụng Certificate Pinning — liên kết chứng chỉ máy chủ trong mã ứng dụng. Không giống như xác minh TLS tiêu chuẩn tin tưởng bất kỳ chứng chỉ nào từ kho hệ thống, Certificate Pinning kiểm tra một chứng chỉ cụ thể hoặc khóa công khai của nó. OkHttp trên Android và TrustKit trên iOS cung cấp các triển khai có sẵn của cơ chế này.

Bắt buộc sử dụng HTTPS và HSTS: tất cả các yêu cầu mạng phải đi qua HTTPS và máy chủ phải trả về tiêu đề Strict-Transport-Security. Đối với Android, thêm android:usesCleartextTraffic="false" vào tệp kê khai — điều này chặn kết nối HTTP ở cấp độ hệ điều hành. iOS chặn HTTP theo mặc định từ iOS 9 qua App Transport Security (ATS).

Triển khai kiểm tra tính toàn vẹn phản hồi: ký các phản hồi máy chủ bằng chữ ký số mà ứng dụng xác minh. Ngay cả khi kẻ tấn công chặn lưu lượng HTTPS (qua proxy với cài đặt lại chứng chỉ), chúng không thể giả mạo chữ ký nếu không có khóa riêng của máy chủ. Sử dụng JWT với chữ ký RS256 hoặc HMAC cho các hoạt động quan trọng.

Ở phía máy chủ, bật HTTP Public Key Pinning (HPKP) — một chỉ thị cho trình duyệt hoặc ứng dụng biết chứng chỉ nào được coi là hợp lệ cho một tên miền nhất định. Tuy nhiên, HPKP đòi hỏi sự thận trọng: cấu hình sai có thể chặn quyền truy cập vào ứng dụng trong một thời gian dài. Google khuyến nghị chỉ sử dụng HPKP kết hợp với chứng chỉ dự phòng.

Theo NIST SP 800-52 Rev. 2 (2024), sự kết hợp giữa TLS 1.3, Certificate Pinning và HSTS loại bỏ 99% các vector tấn công MITM đã biết trên ứng dụng di động. Các nhà phát triển được khuyến nghị kiểm tra bảo vệ bằng các công cụ như mitmproxy trước khi xuất bản ứng dụng.