RASP — ما هو، مبدأ العمل والحماية في الوقت الفعلي

ما هو RASP؟

Runtime Application Self-Protection (RASP) هي تقنية أمان تُدمج في التطبيق أثناء البناء أو عبر وكيل وقت التشغيل. يحلل RASP سلوك التطبيق أثناء التنفيذ ويتخذ قرارات لحظر الهجمات بناءً على السياق: من أين جاء الاستدعاء، وما البيانات المنقولة، وما حالة المكدس. على عكس الأنظمة القائمة على التواقيع، لا يبحث RASP عن أنماط هجوم معروفة — بل يكتشف السلوك الشاذ الذي ينحرف عن سيناريو تنفيذ الكود المتوقع.

تمت صياغة مفهوم RASP من قبل Gartner في عام 2011، وظهرت أولى التطبيقات التجارية في 2014–2015. بالنسبة للمنصات المحمولة، بدأ استخدام RASP بنشاط في عام 2017 عندما أدرك السوق عدم كفاية التعتيم التقليدي. وفقاً لتقرير MarketsandMarkets (2025)، يبلغ حجم سوق حلول RASP 2.8 مليار دولار أمريكي بمعدل نمو سنوي 24.5%. يُوصى بتطبيق RASP وفقاً لمعايير OWASP Mobile Top 10 وPCI DSS 4.0 للتطبيقات التي تعالج بيانات الدفع.

يعمل RASP على مستويين: الاعتراض والتقييم. الاعتراض هو ربط استدعاءات النظام والمكتبات عبر خطافات تُدمج في الكود أثناء البناء أو في وقت التشغيل من خلال التزويد الديناميكي بالأدوات. التقييم هو تحليل سياق الاستدعاء: التحقق من معاملات الإدخال، مكدس الاستدعاءات، حالة البيئة المعزولة، وجود المصحح. يُتخذ القرار بناءً على سياسة الأمان التي يحددها المطور. يمكن أن تكون السياسة صارمة (حظر)، أو لينة (تسجيل)، أو تكيفية (تغيير السلوك حسب مستوى التهديد).

كيف يعمل RASP: البنية والآليات

تتكون بنية وكيل RASP من ثلاثة مكونات: طبقة التزويد بالأدوات، المحلل، والسياسة. طبقة التزويد تعترض استدعاءات النظام واستدعاءات الإطار. المحلل يتحقق من السياق مقابل الأنماط المتوقعة. السياسة تحدد رد الفعل.

تزويد الكود بالأدوات

للتطبيقات المحمولة، يُستخدم التزويد في وقت التجميع: يتم تعديل البايت كود أو الكود الأصلي أثناء البناء — يُدرج فحص قبل كل استدعاء خطر. يُعدل مُجمّع وكيل RASP نقاط الدخول FileOutputStream.write() وRuntime.exec() وClass.forName() وandroid.app.Activity.onStart(). لنظام Android، يُستخدم تحويل بايت كود DEX عبر Gradle plugin؛ لنظام iOS، تعديل ثنائي Mach-O عبر script post-link.

تحليل السياق

عند اعتراض استدعاء، يحلل RASP: الفئة والطريقة المستدعية (من يستدعي)، تتبع المكدس (سلسلة الاستدعاءات)، الوسائط (البيانات المنقولة)، قيمة الإرجاع (ما يُعاد)، الطابع الزمني ومعرف الخيط. يُسجل الشذوذ عندما، على سبيل المثال، يتم استدعاء Runtime.exec() ليس من خيط واجهة المستخدم ولا من كود التطبيق، بل من مكتبة محملة عبر JNI بمسار غير قياسي. أو عندما يتلقى FileOutputStream.write() بيانات تحتوي على بايت كود قابل للتنفيذ بدلاً من رأس PNG المتوقع.

سياسات الاستجابة

يدعم RASP ثلاثة أنواع من الاستجابة: Block — إنهاء التطبيق بشكل طارئ عند اكتشاف هجوم، Log — إرسال تفاصيل الحادث إلى خادم جمع السجلات دون إيقاف التطبيق، Deceive — استبدال قيمة الإرجاع بقيمة مزيفة ليحصل المهاجم على بيانات غير صحيحة. يتيح الجمع بين Log وDeceive جمع معلومات استخباراتية عن المهاجم دون الكشف عن حقيقة الاكتشاف.

// مثال: فحص RASP لاستدعاء Runtime.exec()
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // جارٍ فحص المتصل
        String caller = stack[1].getClassName();

        // إذا كان الاستدعاء ليس من حزمتنا — مشبوه
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // فحص الأمر ضد القائمة السوداء
        String[] blocked = {"su", "frida", "ptrace", "/data/local"};
        for (String pattern : blocked) {
            if (command.contains(pattern)) {
                SecurityPolicy.reportIncident(
                    "BLOCKED_CMD", command, stack
                );
                return new Process(); // deceiving: عملية فارغة
            }
        }

        return null; // السماح بالتنفيذ
    }
}

RASP ضد WAF وأدوات الحماية الأخرى

غالباً ما يُقارن RASP مع جدار حماية تطبيقات الويب (WAF)، لكن الفرق الجوهري يكمن في التموضع. WAF يقع على محيط الشبكة ويحلل فقط طلبات HTTP. RASP يعمل داخل التطبيق ويرى منطق المعالجة.

على عكس التعتيم (ProGuard, DexGuard) الذي يجعل الكود غير قابل للقراءة، فإن RASP يكتشف بنشاط الهجمات أثناء الاستغلال. التعتيم حماية سلبية: إذا أمضى المهاجم وقتاً كافياً في الهندسة العكسية، سيُقرأ الكود. RASP نشط: يرى أن المهاجم يحاول تصحيح التطبيق ويستجيب قبل قراءة سطر واحد من الكود. مزيج التعتيم + RASP يوفر حماية متعددة الطبقات، حيث يبطئ التعتيم التحليل ويقطع RASP الهجوم في مرحلة التزويد بالأدوات.

RASP في التطبيقات المحمولة

حلول RASP المحمولة مُكيفة مع خصوصية Android وiOS. على عكس تطبيقات Java الخادمية، تعمل وكلاء RASP المحمولة في ظروف ذاكرة وبطارية محدودة، مما يتطلب تزويداً خفيفاً بالأدوات.

RASP على Android

على Android، يُدمج وكيل RASP عبر Gradle plugin يُعدل بايت كود DEX أثناء البناء. يعترض الوكيل أكثر من 50 استدعاء نظام، بما في ذلك: Runtime.exec() لاكتشاف تشغيل su أو Frida، Class.forName() لتحديد تحميل الفئات المشبوهة، System.loadLibrary() للتحكم في تحميل المكتبات الأصلية من مسارات غير قياسية. بالإضافة إلى ذلك، يتحقق من وجود المكتبات frida-agent وfrida-helper وlibinject وsubstrate في /proc/self/maps.

RASP على iOS

على iOS، يُنفذ RASP من خلال المعالجة اللاحقة للثنائي Mach-O. iOS أكثر تعقيداً بسبب متطلبات Apple الصارمة لتعديل الثنائيات. يعترض الوكيل استدعاءات الدوال fork() وdlopen() وptrace() ويتحقق من وجود CydiaSubstrate.dylib بين المكتبات المحملة. لا يمكن لـ RASP لنظام iOS تعديل الكود في إصدارات App Store — فقط للتوزيع المؤسسي. بالنسبة لـ App Store، يُوصى بالتزويد في وقت التجميع عبر Swift Macro أو Objective-C method swizzling.

الكشف عن أدوات التحليل

يكتشف RASP المحمول: Frida (عبر التحقق من /proc/self/maps و/data/local/tmp/frida*)، Xposed Framework (عبر التحقق من de.robv.android.xposed.XposedBridge في ClassLoader)، مصحح JDWP (عبر Debug.isDebuggerConnected())، المحاكيات (عبر التحقق من Build.FINGERPRINT وBuild.HARDWARE وBuild.MODEL) وعلامة debuggable في AndroidManifest. وفقاً لتقرير NowSecure Mobile Threat Report (2025)، يكتشف وكيل RASP 89–97% من جلسات Frida المُزوّدة بالأدوات.

تنفيذ وكيل RASP عملياً

دمج RASP في تطبيق محمول يتطلب تكوين التزويد بالأدوات، تحديد السياسات، والتكامل مع نظام SIEM لجمع سجلات الحوادث.

اختيار التنفيذ: وقت التجميع مقابل وقت التشغيل

التزويد في وقت التجميع — تعديل البايت كود أثناء البناء، لا يؤثر على أداء وقت التشغيل. التزويد في وقت التشغيل (عبر Java Agent على الخادم أو Frida على العميل) أكثر مرونة لكنه يضيف 5–10% من الحمل الإضافي. للتطبيقات المحمولة، يُوصى بنهج وقت التجميع لأنه لا يتطلب اتصالاً دائماً بالشبكة ولا يستهلك طاقة البطارية للتحليل.

التكامل مع المكتبات الموجودة

يجب أن يعمل وكيل RASP بشكل صحيح مع SDKs الشائعة. يجب ألا يتم حظر Firebase Crashlytics وGoogle Analytics وAppsee. تكوين القائمة البيضاء للمكتبات المعروفة إلزامي. في تكوين الوكيل، تُحدد الاستثناءات: إذا جاء الاستدعاء من الفئة com.google.firebase — يتم تخطي الفحص. يتم تحديث القائمة البيضاء مع كل إصدار SDK.

مثال على معالجة حادث

عند اكتشاف Frida عبر وكيل RASP، يحدث ما يلي: جمع السياق (تتبع المكدس، إصدار نظام التشغيل، الوقت)، إرسال البيانات إلى خادم التسجيل بشكل مشفر، تنفيذ السياسة (تعطل، تسجيل فقط، أو خداع)، زيادة عداد لتحديد هجوم جماعي. يتم تجميع البيانات من الأجهزة المختلفة على الخادم لتحديد أنماط الهجمات.

class RASPManager {
    fun analyzeAndReact() {
        val threats = detectThreats()
        if (threats.isNotEmpty()) {
            val report = ThreatReport().apply {
                threats = threats
                timestamp = System.currentTimeMillis()
                deviceId = DeviceInfo.getHashedId()
                stackTrace = Thread
                    .currentThread()
                    .stackTrace
                    .take(10)
                    .toList()
            }

            val policy = SecurityPolicy.getPolicy(threats.maxBy { it.severity })

            when (policy) {
                Policy.BLOCK   -> throw SecurityException("Protection triggered")
                Policy.LOG     -> ServerLogger.sendReport(report)
                Policy.DECEIVE -> DeceptionLayer.activate(report)
            }
        }
    }
}

القيود والإيجابيات الكاذبة

RASP ليس حلاً سحرياً. التقنية لها قيود يجب مراعاتها عند تصميم الحماية.

الأداء

كل استدعاء معترض يضيف فحصاً للسياق. مع التكوين العدواني (اعتراض جميع استدعاءات IO وexec)، قد ينخفض الأداء بنسبة 5–15%. وقت بدء التشغيل بالغ الأهمية للتطبيقات المحمولة: تهيئة RASP تضيف 200–500 مللي ثانية عند الإقلاع. يُوصى بالتزويد الانتقائي — فقط الدوال الحرجة، وليس كل الدوال الممكنة. إنشاء ملفات تعريف الأداء مع وكيل RASP إلزامي أثناء مرحلة الاختبار.

الإيجابيات الكاذبة

قد يحجب RASP سلوكاً شرعياً: Firebase Crashlytics التي ترسل مكدس الأخطاء عبر استدعاء شبكة قد تُعتبر تسريباً للبيانات؛ Google Play Integrity API الذي يتحقق من سلامة الجهاز قد يُحدد كاستدعاء مشبوه. لتقليل الإيجابيات الكاذبة، هناك حاجة إلى فترة تعلم (learning mode) مدتها 7–14 يوماً، يسجل خلالها RASP فقط لكنه لا يحظر.

تجاوز RASP

إذا حصل المهاجم على وصول على مستوى النواة (عبر استغلال ثغرة في النواة)، لا يمكن لـ RASP الوثوق حتى في فحوصاته الخاصة — يعمل الوكيل في مساحة المستخدم ويرى فقط ما تسمح له النواة برؤيته. لمنع التجاوز على مستوى النواة، يُستخدم التحقق من سلسلة الإقلاع الآمن (Secure Boot Chain) مع المصادقة من الخادم. بالإضافة إلى ذلك، يجب أن يكون وكيل RASP نفسه مُعَتّماً ومحمياً من التصحيح — وإلا سيزيل المهاجم أو يعطل RASP قبل بدء الهجوم.