حملات MITM در اپلیکیشن‌های موبایل — چیست، انواع و محافظت از رهگیری

حمله MITM چیست؟

Man-in-the-Middle (MITM) — نوعی حمله سایبری است که در آن مهاجم مخفیانه در کانال ارتباطی بین دو طرف نفوذ می‌کند. مهاجم می‌تواند داده‌های ارسالی را رهگیری، خوانده و تغییر دهد، در حالی که برای هر دو طرف نامرئی می‌ماند.

در اپلیکیشن‌های موبایل، حملات MITM به ویژه خطرناک هستند، زیرا دستگاه‌ها دائماً به شبکه‌های مختلف — خانگی، اداری، Wi-Fi عمومی در کافه‌ها و فرودگاه‌ها — متصل می‌شوند. هر تغییر شبکه به طور بالقوه پنجره‌ای برای حمله ایجاد می‌کند. طبق Verizon Mobile Security Index (2025)، ۴۳٪ از سازمان‌ها حداقل یک بار با حملات MITM بر روی دستگاه‌های موبایل شرکتی مواجه شده‌اند.

خطر اصلی MITM — پنهان‌کاری: کاربر و سرور سیگنال‌هایی درباره رهگیری دریافت نمی‌کنند. جلسه عادی به نظر می‌رسد، داده‌ها منتقل می‌شوند، خطاهای گواهی وجود ندارد (اگر مهاجم از گواهی خود استفاده کند). تشخیص حمله فقط در سطح زیرساخت شبکه یا با ابزارهای تخصصی امکان‌پذیر است.

توسعه‌دهنده باید مکانیسم‌های حملات MITM را درک کند تا محافظت را در سطح اپلیکیشن طراحی کند، نه اینکه صرفاً به امنیت لایه حمل و نقل تکیه کند.

انواع اصلی حملات MITM

طبقه‌بندی حملات MITM شامل چند نوع است که در روش نفوذ به کانال ارتباطی متفاوت هستند. در توسعه موبایل، سه نوع بیشترین اهمیت را دارند.

ARP Spoofing در شبکه محلی

ARP Spoofing — تکنیکی است که در آن مهاجم بسته‌های ARP جعلی به شبکه محلی ارسال می‌کند و آدرس MAC خود را با آدرس IP دروازه مرتبط می‌سازد. پس از آن، تمام ترافیک قربانی از طریق دستگاه مهاجم هدایت می‌شود که آن را به دروازه ارسال کرده و نامرئی می‌ماند.

برای انجام حمله، ابزارهایی مانند Ettercap یا BetterCAP که ARP-spoofing را خودکار می‌کنند، کافی هستند. حمله فقط در یک زیرشبکه امکان‌پذیر است، بنابراین کاربران شبکه‌های 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 ناامن کاهش می‌دهد. این تکنیک از این واقعیت استفاده می‌کند که بسیاری از کاربران به جای https://example.com به صورت دستی example.com را وارد می‌کنند و اولین اتصال از طریق HTTP برقرار می‌شود.

ابزارهایی مانند sslstrip (Moxie Marlinspike، ۲۰۰۹) و 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 از iOS 9 به طور پیش‌فرض HTTP را از طریق 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 ۹۹٪ از بردارهای شناخته‌شده حملات MITM بر اپلیکیشن‌های موبایل را از بین می‌برد. به توسعه‌دهندگان توصیه می‌شود قبل از انتشار اپلیکیشن، محافظت را با ابزارهایی مانند mitmproxy آزمایش کنند.