هجمات 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 تحمي أيضًا من الهجوم الأول، ولكنها تتطلب تسجيل النطاق مسبقًا.

كيف يعمل هجوم 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" إلى البيان — وهذا يمنع اتصالات 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 قبل نشر التطبيق.