RASP — bu nədir, iş prinsipi və real vaxtda qorunma

RASP nədir?

Runtime Application Self-Protection (RASP) — qurma mərhələsində və ya icra agenti vasitəsilə tətbiqə inteqrasiya olunan təhlükəsizlik texnologiyası. RASP tətbiqin davranışını icra zamanı təhlil edir və kontekstə əsaslanaraq hücumların bloklanması barədə qərarlar qəbul edir: çağırışın haradan gəldiyi, hansı məlumatların ötürüldüyü, yığının vəziyyəti. İmza sistemlərindən fərqli olaraq, RASP məlum hücum nümunələrini axtarmır — kodun gözlənilən icra ssenarisindən kənara çıxan anormal davranışı aşkarlayır.

RASP konsepsiyası Gartner tərəfindən 2011-ci ildə rəsmiləşdirilmiş, ilk kommersiya tətbiqləri isə 2014–2015-ci illərdə ortaya çıxmışdır. Mobil platformalar üçün RASP 2017-ci ildən etibarən aktiv şəkildə tətbiq olunmağa başlamışdır, belə ki, bazar ənənəvi obfuskasiyanın yetərsizliyini dərk etmişdir. MarketsandMarkets (2025) hesabatına görə, RASP həlləri bazarının həcmi 2,8 milyard USD təşkil edir, illik artım isə 24,5% təşkil edir. RASP-nin tətbiqi OWASP Mobile Top 10 və PCI DSS 4.0 standartları tərəfindən ödəniş məlumatlarını emal edən tətbiqlər üçün tövsiyə olunur.

RASP iki səviyyədə işləyir: interception və assessment. Interception — qurma mərhələsində və ya dinamik instrumentasiya vasitəsilə icra zamanı koda daxil edilən hooklar vasitəsilə sistem və kitabxana çağırışlarının ələ keçirilməsi. Assessment — çağırış kontekstinin təhlili: giriş parametrlərinin, çağırış yığınının, sandbox vəziyyətinin, debuggerin mövcudluğunun yoxlanılması. Qərar tərtibatçı tərəfindən müəyyən edilmiş təhlükəsizlik siyasəti əsasında qəbul edilir. Siyasət sərt (blokla), yumşaq (logla) və ya adaptiv (təhdid səviyyəsindən asılı olaraq davranışı dəyiş) ola bilər.

RASP necə işləyir: arxitektura və mexanizmlər

RASP agentinin arxitekturası üç komponentdən ibarətdir: instrumentasiya təbəqəsi, analizator və siyasət. Instrumentasiya təbəqəsi sistem çağırışlarını və framework çağırışlarını ələ keçirir. Analizator konteksti gözlənilən nümunələrə uyğunluq baxımından yoxlayır. Siyasət reaksiyanı müəyyən edir.

Kodun instrumentasiyası

Mobil tətbiqlər üçün compile-time instrumentasiyası istifadə olunur: baytkod və ya nativ kod qurma mərhələsində dəyişdirilir — hər bir təhlükəli çağırışdan əvvəl yoxlama əlavə olunur. RASP agentinin kompilyatoru FileOutputStream.write(), Runtime.exec(), Class.forName() və android.app.Activity.onStart() giriş nöqtələrini dəyişdirir. Android üçün Gradle plugin vasitəsilə DEX-baytkodun transformasiyası; iOS üçün isə post-link skripti vasitəsilə Mach-O binar faylının dəyişdirilməsi istifadə olunur.

Kontekstin təhlili

Çağırış ələ keçirilərkən RASP təhlil edir: çağıran sinif və metodu (kim çağırır), yığın izini (çağırışlar zənciri), arqumentləri (ötürülən məlumatlar), qaytarılan dəyəri (nə qaytarılır), vaxt damğası və thread identifikatorunu. Anomaliya qeydə alınır, məsələn, Runtime.exec() UI thread-dən və tətbiq kodundan deyil, JNI vasitəsilə qeyri-standart yolla yüklənmiş kitabxanadan çağırıldıqda. Və ya FileOutputStream.write() gözlənilən PNG başlığı əvəzinə icra olunan baytkod ehtiva edən məlumatlar qəbul etdikdə.

Reaksiya siyasətləri

RASP üç növ reaksiyanı dəstəkləyir: Block — hücum aşkarlandıqda tətbiqin təcili dayandırılması, Log — tətbiqi dayandırmadan hadisə təfərrüatlarının log toplama serverinə göndərilməsi, Deceive — hücumçunun yanlış məlumatlar alması üçün qaytarılan dəyərin saxta ilə əvəz edilməsi. Log və Deceive birləşməsi aşkarlanma faktını gizlətməklə hücumçu haqqında kəşfiyyat məlumatları toplamağa imkan verir.

// Nümunə: Runtime.exec() çağırışının RASP yoxlaması
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // Zəng edənin yoxlanması
        String caller = stack[1].getClassName();

        // Əgər çağırış bizim paketdən deyilsə — şübhəli
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Əmrin qara siyahıya qarşı yoxlanması
        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: boş proses
            }
        }

        return null; // icraya icazə ver
    }
}

RASP vs WAF və digər qoruma vasitələri

RASP tez-tez Web Application Firewall (WAF) ilə müqayisə edilir, lakin əsas fərq yerləşmə nöqtəsindədir. WAF şəbəkə perimetrində yerləşir və yalnız HTTP sorğularını təhlil edir. RASP tətbiq daxilində işləyir və emal məntiqini görür.

Obfuskasiyadan (ProGuard, DexGuard) fərqli olaraq, kodun oxunmasını çətinləşdirən, RASP hücumları aktiv şəkildə istismar zamanı aşkarlayır. Obfuskasiya passiv qorumadır: əgər hücumçu reverse engineering-ə kifayət qədər vaxt sərf edərsə, kod oxunacaq. RASP aktivdir: o, hücumçunun tətbiqi debug etməyə çalışdığını görür və kodun bir sətri belə oxunmadan reaksiya verir. Obfuskasiya + RASP kombinasiyası çoxqatlı qoruma təmin edir, burada obfuskasiya təhlili ləngidir, RASP isə hücumu instrumentasiya mərhələsində dayandırır.

RASP mobil tətbiqlərdə

Mobil RASP həlləri Android və iOS spesifikasına uyğunlaşdırılmışdır. Server Java tətbiqlərindən fərqli olaraq, mobil RASP agentləri məhdud yaddaş və batareya şəraitində işləyir ki, bu da yüngül instrumentasiya tələb edir.

Android-də RASP

Android-də RASP agenti qurma mərhələsində DEX-baytkodunu dəyişdirən Gradle plugin vasitəsilə daxil edilir. Agent 50-dən çox sistem çağırışını ələ keçirir, o cümlədən: Runtime.exec() su və ya Frida-nın işə salınmasını aşkarlamaq üçün, Class.forName() şübhəli siniflərin yüklənməsini müəyyən etmək üçün, System.loadLibrary() qeyri-standart yollardan nativ kitabxanaların yüklənməsinə nəzarət etmək üçün. Əlavə olaraq /proc/self/maps faylında frida-agent, frida-helper, libinject və substrate kitabxanalarının mövcudluğu yoxlanılır.

iOS-da RASP

iOS-da RASP Mach-O binar faylının post-emalı vasitəsilə həyata keçirilir. iOS üçün mürəkkəblik daha yüksəkdir, çünki Apple-ın binar faylların dəyişdirilməsinə dair ciddi tələbləri var. Agent fork(), dlopen(), ptrace() funksiyalarının çağırışlarını ələ keçirir və yüklənmiş kitabxanalarda CydiaSubstrate.dylib-nin mövcudluğunu yoxlayır. iOS üçün RASP App Store build-də kodu dəyişdirə bilməz — yalnız Enterprise paylanması üçün. App Store üçün Swift Macro və ya Objective-C method swizzling vasitəsilə compile-time instrumentasiyasından istifadə etmək tövsiyə olunur.

Analiz alətlərinin aşkarlanması

Mobil RASP aşkarlayır: Frida (/proc/self/maps və /data/local/tmp/frida* yoxlanması vasitəsilə), Xposed Framework (ClassLoader-də de.robv.android.xposed.XposedBridge yoxlanması vasitəsilə), JDWP debuggeri (Debug.isDebuggerConnected() vasitəsilə), emulyatorlar (Build.FINGERPRINT, Build.HARDWARE, Build.MODEL yoxlanması vasitəsilə) və AndroidManifest-də debuggable bayrağı. NowSecure Mobile Threat Report (2025) məlumatlarına görə, RASP agenti Frida-nın 89–97% instrumentasiya edilmiş seanslarını aşkarlayır.

RASP agentinin praktikada tətbiqi

RASP-nin mobil tətbiqə daxil edilməsi instrumentasiyanın konfiqurasiyasını, siyasətlərin müəyyən edilməsini və hadisə loglarının toplanması üçün SIEM sistemi ilə inteqrasiyanı tələb edir.

Tətbiq seçimi: compile-time vs runtime

Compile-time instrumentasiyası — qurma mərhələsində baytkodun dəyişdirilməsi, icra zamanı məhsuldarlığa təsir göstərmir. Runtime instrumentasiyası (serverdə Java Agent və ya müştəridə Frida vasitəsilə) — daha çevikdir, lakin 5–10% əlavə yük əlavə edir. Mobil tətbiqlər üçün compile-time yanaşması tövsiyə olunur, çünki o, daimi şəbəkə qoşulması tələb etmir və təhlil üçün batareya sərf etmir.

Mövcud kitabxanalarla inteqrasiya

RASP agenti məşhur SDK-larla düzgün işləməlidir. Firebase Crashlytics, Google Analytics və Appsee bloklanmamalıdır. Tanınmış kitabxanalar üçün whitelist konfiqurasiyası məcburidir. Agentin konfiqurasiyasında istisnalar müəyyən edilir: əgər çağırış com.google.firebase sinfindən gəlirsə — yoxlama buraxılır. Whitelist hər SDK buraxılışı ilə yenilənir.

Hadisənin işlənməsi nümunəsi

RASP agenti tərəfindən Frida aşkarlandıqda: kontekstin toplanması (yığın izi, OS versiyası, vaxt), məlumatların şifrələnmiş formada loglama serverinə göndərilməsi, siyasətin icrası (crash, log-only və ya deceive), kütləvi hücumun müəyyən edilməsi üçün sayğacın artırılması baş verir. Müxtəlif cihazlardan məlumatlar hücum nümunələrini müəyyən etmək üçün serverdə toplanır.

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)
            }
        }
    }
}

Məhdudiyyətlər və yanlış həyəcanlar

RASP gümüş güllə deyil. Texnologiyanın qoruma layihələndirilərkən nəzərə alınmalı olan məhdudiyyətləri var.

Məhsuldarlıq

Hər ələ keçirilmiş çağırış kontekst yoxlaması əlavə edir. Aqressiv konfiqurasiyada (bütün IO və exec çağırışlarının ələ keçirilməsi) məhsuldarlıq 5–15% düşə bilər. Mobil tətbiqlər üçün başlanğıc vaxtı kritikdir: RASP inisializasiyası başlanğıcda 200–500 ms əlavə edir. Nöqtəli instrumentasiya tövsiyə olunur — bütün mümkün funksiyalar deyil, yalnız kritik funksiyalar. Profilləşdirmə RASP agenti ilə test mərhələsində məcburidir.

Yanlış həyəcanlar

RASP qanuni davranışı bloklaya bilər: şəbəkə çağırışı vasitəsilə xəta yığını göndərən Firebase Crashlytics məlumat sızması kimi qiymətləndirilə bilər; cihaz bütövlüyünü yoxlayan Google Play Integrity API şübhəli çağırış kimi identifikasiya edilə bilər. Yanlış həyəcanları azaltmaq üçün 7–14 gün davam edən öyrənmə dövrü (learning mode) lazımdır, bu müddət ərzində RASP yalnız loglayır, lakin bloklamır.

RASP-nin keçilməsi

Əgər hücumçu kernel səviyyəsində giriş əldə edərsə (kernel eksployti vasitəsilə), RASP hətta öz yoxlamalarına da etibar edə bilməz — agent istifadəçi məkanında işləyir və kernelin icazə verdiyini görür. Kernel səviyyəsində keçilmənin qarşısını almaq üçün server attestasiyası ilə birlikdə Secure Boot Chain yoxlaması istifadə olunur. Bundan əlavə, RASP agentinin özü obfuskasiya olunmalı və debugdan qorunmalıdır — əks halda hücumçu hücuma başlamazdan əvvəl RASP-ni siləcək və ya söndürəcək.