RASP — چیست، اصل کار و محافظت در زمان واقعی

RASP چیست؟

Runtime Application Self-Protection (RASP) — فناوری امنیتی که در مرحله ساخت یا از طریق عامل زمان اجرا در برنامه ادغام می‌شود. RASP رفتار برنامه را در حین اجرا تحلیل می‌کند و بر اساس زمینه تصمیم به مسدودسازی حملات می‌گیرد: فراخوانی از کجا آمده، چه داده‌هایی منتقل می‌شوند، وضعیت پشته چگونه است. بر خلاف سیستم‌های امضایی، RASP به دنبال الگوهای شناخته‌شده حملات نمی‌گردد — رفتار غیرعادی که از سناریوی مورد انتظار اجرای کد منحرف می‌شود را شناسایی می‌کند.

مفهوم RASP توسط Gartner در سال 2011 رسمی شد و اولین پیاده‌سازی‌های تجاری در سال‌های 2014–2015 ظاهر شدند. برای پلتفرم‌های موبایل، RASP از سال 2017 به طور فعال مورد استفاده قرار گرفت، زمانی که بازار به ناکافی بودن مبهم‌سازی سنتی پی برد. طبق گزارش MarketsandMarkets (2025)، حجم بازار راه‌حل‌های RASP 2.8 میلیارد USD با رشد سالانه 24.5% است. استقرار RASP توسط استانداردهای OWASP Mobile Top 10 و PCI DSS 4.0 برای برنامه‌های پردازش‌کننده داده‌های پرداختی توصیه می‌شود.

RASP در دو سطح کار می‌کند: interception و assessment. Interception — رهگیری فراخوانی‌های سیستم و کتابخانه از طریق هوک‌هایی که در مرحله ساخت یا در زمان اجرا از طریق ابزارگذاری پویا در کد جاسازی می‌شوند. Assessment — تحلیل زمینه فراخوانی: بررسی پارامترهای ورودی، پشته فراخوانی، وضعیت sandbox، وجود اشکال‌زدا. تصمیم بر اساس سیاست امنیتی تعیین‌شده توسط توسعه‌دهنده گرفته می‌شود. سیاست می‌تواند سخت (مسدود کردن)، نرم (ثبت رویداد) یا تطبیقی (تغییر رفتار بسته به سطح تهدید) باشد.

RASP چگونه کار می‌کند: معماری و مکانیزم‌ها

معماری عامل RASP از سه مؤلفه تشکیل شده است: لایه ابزارگذاری، تحلیلگر و سیاست. لایه ابزارگذاری فراخوانی‌های سیستم و فراخوانی‌های چارچوب را رهگیری می‌کند. تحلیلگر زمینه را از نظر مطابقت با الگوهای مورد انتظار بررسی می‌کند. سیاست واکنش را تعیین می‌کند.

ابزارگذاری کد

برای برنامه‌های موبایل از ابزارگذاری در زمان کامپایل (compile-time) استفاده می‌شود: بایت‌کد یا کد بومی در مرحله ساخت تغییر می‌کند — قبل از هر فراخوانی خطرناک یک بررسی درج می‌شود. کامپایلر عامل RASP نقاط ورودی FileOutputStream.write()، Runtime.exec()، Class.forName() و android.app.Activity.onStart() را تغییر می‌دهد. برای Android از تبدیل DEX-بایت‌کد از طریق Gradle plugin استفاده می‌شود؛ برای iOS از تغییر فایل باینری Mach-O از طریق اسکریپت post-link.

تحلیل زمینه

هنگام رهگیری فراخوانی، RASP تحلیل می‌کند: کلاس و متد فراخواننده (چه کسی فراخوانی می‌کند)، ردیابی پشته (زنجیره فراخوانی‌ها)، آرگومان‌ها (داده‌های منتقل‌شده)، مقدار بازگشتی (آنچه بازگردانده می‌شود)، برچسب زمانی و شناسه نخ. ناهنجاری زمانی ثبت می‌شود که، برای مثال، Runtime.exec() از نخ UI و از کد برنامه فراخوانی نشود، بلکه از کتابخانه‌ای که از طریق JNI با مسیر غیراستاندارد بارگذاری شده است. یا زمانی که FileOutputStream.write() داده‌های حاوی بایت‌کد اجرایی به جای هدر PNG مورد انتظار دریافت کند.

سیاست‌های واکنش

RASP از سه نوع واکنش پشتیبانی می‌کند: Block — خاتمه اضطراری برنامه هنگام شناسایی حمله، Log — ارسال جزئیات حادثه به سرور جمع‌آوری لاگ بدون توقف برنامه، Deceive — جایگزینی مقدار بازگشتی با مقدار جعلی تا مهاجم داده‌های نادرست دریافت کند. ترکیب Log و Deceive امکان جمع‌آوری اطلاعات اطلاعاتی درباره مهاجم را بدون افشای واقعیت شناسایی فراهم می‌کند.

// مثال: بررسی فراخوانی Runtime.exec() توسط RASP
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // بررسی caller
        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 اغلب با Web Application Firewall (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 تغییر دهد — فقط برای توزیع Enterprise. برای 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 برای جمع‌آوری لاگ‌های حوادث دارد.

انتخاب پیاده‌سازی: compile-time در مقابل runtime

ابزارگذاری در زمان کامپایل (compile-time) — تغییر بایت‌کد در مرحله ساخت که بر عملکرد در زمان اجرا تأثیر نمی‌گذارد. ابزارگذاری در زمان اجرا (runtime) (از طریق Java Agent در سرور یا Frida در کلاینت) — انعطاف‌پذیرتر است، اما 5–10% سربار اضافه می‌کند. برای برنامه‌های موبایل رویکرد compile-time توصیه می‌شود، زیرا نیاز به اتصال دائمی به شبکه ندارد و باتری را برای تحلیل مصرف نمی‌کند.

ادغام با کتابخانه‌های موجود

عامل RASP باید با SDKهای محبوب به درستی کار کند. Firebase Crashlytics، Google Analytics و Appsee نباید مسدود شوند. پیکربندی whitelist برای کتابخانه‌های شناخته‌شده الزامی است. در پیکربندی عامل استثناها تعیین می‌شوند: اگر فراخوانی از کلاس com.google.firebase باشد — بررسی رد می‌شود. Whitelist با هر انتشار SDK به‌روزرسانی می‌شود.

نمونه پردازش حادثه

پس از شناسایی Frida توسط عامل RASP: جمع‌آوری زمینه (ردیابی پشته، نسخه سیستم‌عامل، زمان)، ارسال داده‌ها به سرور ثبت رویداد به صورت رمزنگاری‌شده، اجرای سیاست (crash، log-only یا deceive)، افزایش شمارنده برای تعیین حمله گسترده. داده‌های دستگاه‌های مختلف برای شناسایی الگوهای حمله در سرور تجمیع می‌شوند.

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 را قبل از شروع حمله حذف یا غیرفعال می‌کند.