RASP — bu nima, ishlash prinsipi va real vaqtda himoya

RASP nima?

Runtime Application Self-Protection (RASP) — qurish bosqichida yoki ish vaqti agenti orqali ilovaga integratsiya qilinadigan xavfsizlik texnologiyasi. RASP ilovaning bajarilish vaqtidagi xatti-harakatini tahlil qiladi va kontekstga asoslanib hujumlarni bloklash to'g'risida qarorlar qabul qiladi: chaqiruv qayerdan kelganligi, qanday ma'lumotlar uzatilayotganligi, stekning holati. Imzo tizimlaridan farqli o'laroq, RASP ma'lum hujum naqshlarini qidirmaydi — koddan kutilgan bajarilish ssenariysidan chetga chiqadigan anormal xatti-harakatni aniqlaydi.

RASP kontseptsiyasi Gartner tomonidan 2011 yilda rasmiylashtirilgan, birinchi tijorat tatbiqlari esa 2014–2015 yillarda paydo bo'lgan. Mobil platformalar uchun RASP 2017 yildan boshlab faol qo'llanila boshlandi, chunki bozor an'anaviy obfuskatsiyaning yetarsizligini angladi. MarketsandMarkets (2025) hisobotiga ko'ra, RASP yechimlari bozorining hajmi 2,8 mlrd USD ni tashkil etadi, yillik o'sish esa 24,5% ni tashkil etadi. RASP ni joriy etish OWASP Mobile Top 10 va PCI DSS 4.0 standartlari tomonidan to'lov ma'lumotlarini qayta ishlaydigan ilovalar uchun tavsiya etiladi.

RASP ikki darajada ishlaydi: interception va assessment. Interception — qurish bosqichida yoki dinamik instrumentatsiya orqali ish vaqtida kodga o'rnatilgan hooklar orqali tizim va kutubxona chaqiruvlarini tutib olish. Assessment — chaqiruv kontekstini tahlil qilish: kirish parametrlarini, chaqiruvlar stekini, sandbox holatini, tuzatuvchi mavjudligini tekshirish. Qaror dasturchi tomonidan belgilangan xavfsizlik siyosati asosida qabul qilinadi. Siyosat qattiq (blokla), yumshoq (logla) yoki adaptiv (tahdid darajasiga qarab xatti-harakatni o'zgartir) bo'lishi mumkin.

RASP qanday ishlaydi: arxitektura va mexanizmlar

RASP agentining arxitekturasi uch komponentdan iborat: instrumentatsiya qatlami, analizator va siyosat. Instrumentatsiya qatlami tizim chaqiruvlari va framework chaqiruvlarini tutib oladi. Analizator kontekstni kutilgan naqshlarga muvofiqlik nuqtai nazaridan tekshiradi. Siyosat reaksiyani belgilaydi.

Kodning instrumentatsiyasi

Mobil ilovalar uchun compile-time instrumentatsiyasi qo'llaniladi: baytkod yoki mahalliy kod qurish bosqichida o'zgartiriladi — har bir xavfli chaqiruvdan oldin tekshirish qo'shiladi. RASP agentining kompilyatori FileOutputStream.write(), Runtime.exec(), Class.forName() va android.app.Activity.onStart() kirish nuqtalarini o'zgartiradi. Android uchun Gradle plugin orqali DEX-baytkodni transformatsiya qilish; iOS uchun esa post-link skript orqali Mach-O ikkilik faylini o'zgartirish qo'llaniladi.

Kontekstni tahlil qilish

Chaqiruv tutib olinganda RASP tahlil qiladi: chaqiruvchi sinf va metod (kim chaqiradi), stek izi (chaqiruvlar zanjiri), argumentlar (uzatilayotgan ma'lumotlar), qaytarilgan qiymat (nima qaytariladi), vaqt tamg'asi va thread identifikatori. Anomaliya qayd etiladi, masalan, Runtime.exec() UI threadidan va ilova kodidan emas, balki JNI orqali nostandart yo'l bilan yuklangan kutubxonadan chaqirilganda. Yoki FileOutputStream.write() kutilgan PNG sarlavhasi o'rniga bajariladigan baytkodni o'z ichiga olgan ma'lumotlarni qabul qilganda.

Reaksiya siyosatlari

RASP uch turdagi reaksiyani qo'llab-quvvatlaydi: Block — hujum aniqlanganda ilovani favqulodda to'xtatish, Log — ilovani to'xtatmasdan hodisa tafsilotlarini log yig'ish serveriga yuborish, Deceive — hujumchi noto'g'ri ma'lumot olishi uchun qaytarilgan qiymatni soxta bilan almashtirish. Log va Deceive kombinatsiyasi aniqlanish faktini yashirgan holda hujumchi haqida razvedka ma'lumotlarini to'plash imkonini beradi.

// Runtime.exec() chaqiruvini RASP tekshiruvi namunasi
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // Chaqiruvchini tekshirish
        String caller = stack[1].getClassName();

        // Agar chaqiruv bizning paketimizdan bo'lmasa — shubhali
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Buyruqni qora ro'yxatga tekshirish
        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'sh jarayon
            }
        }

        return null; // bajarishga ruxsat berish
    }
}

RASP vs WAF va boshqa himoya vositalari

RASP tez-tez Web Application Firewall (WAF) bilan solishtiriladi, ammo asosiy farq joylashuvidadir. WAF tarmoq perimetrida joylashgan va faqat HTTP so'rovlarini tahlil qiladi. RASP ilova ichida ishlaydi va qayta ishlash mantig'ini ko'radi.

Obfuskatsiyadan (ProGuard, DexGuard) farqli o'laroq, kodni o'qib bo'lmaydigan qiladigan, RASP hujumlarni faol ravishda ekspluatatsiya paytida aniqlaydi. Obfuskatsiya passiv himoyadir: agar hujumchi reverse engineering-ga yetarli vaqt sarflasa, kod o'qiladi. RASP faol: u hujumchining ilovani tuzatishga urinayotganini ko'radi va kodning bir satri ham o'qilmasdan reaksiya beradi. Obfuskatsiya + RASP kombinatsiyasi ko'p qatlamli himoyani ta'minlaydi, bunda obfuskatsiya tahlilni sekinlashtiradi, RASP esa hujumni instrumentatsiya bosqichida to'xtatadi.

RASP mobil ilovalarda

Mobil RASP yechimlari Android va iOS xususiyatlariga moslashtirilgan. Server Java ilovalaridan farqli o'laroq, mobil RASP agentlari cheklangan xotira va batareya sharoitida ishlaydi, bu esa engil instrumentatsiyani talab qiladi.

Android da RASP

Android da RASP agenti qurish bosqichida DEX-baytkodni o'zgartiruvchi Gradle plugin orqali o'rnatiladi. Agent 50 dan ortiq tizim chaqiruvini tutib oladi, jumladan: Runtime.exec() su yoki Frida ni ishga tushirishni aniqlash uchun, Class.forName() shubhali sinflar yuklanishini aniqlash uchun, System.loadLibrary() nostandart yo'llardan mahalliy kutubxonalar yuklanishini nazorat qilish uchun. Qo'shimcha ravishda /proc/self/maps faylida frida-agent, frida-helper, libinject va substrate kutubxonalarining mavjudligi tekshiriladi.

iOS da RASP

iOS da RASP Mach-O ikkilik faylining qayta ishlanishi orqali amalga oshiriladi. iOS uchun murakkablik yuqoriroq, chunki Apple ikkilik fayllarni o'zgartirishga qattiq talablar qo'yadi. Agent fork(), dlopen(), ptrace() funksiyalarining chaqiruvlarini tutib oladi va yuklangan kutubxonalarda CydiaSubstrate.dylib mavjudligini tekshiradi. iOS uchun RASP App Store build da kodni o'zgartira olmaydi — faqat Enterprise tarqatish uchun. App Store uchun Swift Macro yoki Objective-C method swizzling orqali compile-time instrumentatsiyasidan foydalanish tavsiya etiladi.

Tahlil vositalarini aniqlash

Mobil RASP aniqlaydi: Frida (/proc/self/maps va /data/local/tmp/frida* tekshirish orqali), Xposed Framework (ClassLoader da de.robv.android.xposed.XposedBridge tekshirish orqali), JDWP tuzatuvchisi (Debug.isDebuggerConnected() orqali), emulyatorlar (Build.FINGERPRINT, Build.HARDWARE, Build.MODEL tekshirish orqali) va AndroidManifest dagi debuggable bayrog'i. NowSecure Mobile Threat Report (2025) ma'lumotlariga ko'ra, RASP agenti Frida ning 89–97% instrumentatsiya qilingan seanslarini aniqlaydi.

RASP agentini amalda joriy qilish

RASP ni mobil ilovaga kiritish instrumentatsiyani sozlash, siyosatlarni belgilash va hodisa loglarini yig'ish uchun SIEM tizimi bilan integratsiyani talab qiladi.

Amalga oshirishni tanlash: compile-time vs runtime

Compile-time instrumentatsiyasi — qurish bosqichida baytkodni o'zgartirish, ish vaqti davomida samaradorlikka ta'sir qilmaydi. Runtime instrumentatsiyasi (serverda Java Agent yoki mijozda Frida orqali) — moslashuvchanroq, lekin 5–10% qo'shimcha yuk qo'shadi. Mobil ilovalar uchun compile-time yondashuvi tavsiya etiladi, chunki u doimiy tarmoq ulanishini talab qilmaydi va tahlil uchun batareyani sarflamaydi.

Mavjud kutubxonalar bilan integratsiya

RASP agenti mashhur SDK lar bilan to'g'ri ishlashi kerak. Firebase Crashlytics, Google Analytics va Appsee bloklanmasligi kerak. Ma'lum kutubxonalar uchun whitelist sozlash majburiydir. Agent konfiguratsiyasida istisnolar belgilanadi: agar chaqiruv com.google.firebase sinfidan kelsa — tekshirish o'tkazib yuboriladi. Whitelist har bir SDK chiqarilishi bilan yangilanadi.

Hodisani qayta ishlash namunasi

RASP agenti tomonidan Frida aniqlanganda: kontekstni yig'ish (stek izi, OS versiyasi, vaqt), ma'lumotlarni shifrlangan shaklda loglash serveriga yuborish, siyosatni bajarish (crash, log-only yoki deceive), ommaviy hujumni aniqlash uchun hisoblagichni oshirish sodir bo'ladi. Turli qurilmalardan ma'lumotlar hujum naqshlarini aniqlash uchun serverda yig'iladi.

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

Cheklovlar va noto'g'ri signallar

RASP kumush o'q emas. Texnologiya himoyani loyihalashda hisobga olinishi kerak bo'lgan cheklovlarga ega.

Samaradorlik

Har bir tutib olingan chaqiruv kontekstni tekshirishni qo'shadi. Agressiv konfiguratsiyada (barcha IO va exec chaqiruvlarini tutib olish) samaradorlik 5–15% ga tushishi mumkin. Mobil ilovalar uchun ishga tushirish vaqti muhim: RASP ishga tushirilishi 200–500 ms qo'shadi. Nuqtali instrumentatsiya tavsiya etiladi — barcha mumkin bo'lgan funksiyalar emas, faqat muhim funksiyalar. Profillash RASP agenti bilan sinov bosqichida majburiydir.

Noto'g'ri signallar

RASP qonuniy xatti-harakatni bloklashi mumkin: tarmoq chaqiruvi orqali xato stekini yuboradigan Firebase Crashlytics ma'lumotlarni chiqarib yuborish deb baholanishi mumkin; qurilma yaxlitligini tekshiradigan Google Play Integrity API shubhali chaqiruv sifatida identifikatsiya qilinishi mumkin. Noto'g'ri signallarni kamaytirish uchun 7–14 kun davom etadigan o'rganish davri (learning mode) zarur, bu vaqt davomida RASP faqat loglaydi, lekin bloklamaydi.

RASP ni chetlab o'tish

Agar hujumchi yadro darajasida kirishga ega bo'lsa (yadro eksploiti orqali), RASP hatto o'z tekshiruvlariga ham ishonishi mumkin emas — agent foydalanuvchi makonida ishlaydi va yadro ruxsat bergan narsani ko'radi. Yadro darajasida chetlab o'tishning oldini olish uchun server attestatsiyasi bilan birgalikda Secure Boot Chain tekshiruvi qo'llaniladi. Bundan tashqari, RASP agentining o'zi obfuskatsiya qilinishi va tuzatishdan himoyalangan bo'lishi kerak — aks holda hujumchi hujum boshlanishidan oldin RASP ni olib tashlaydi yoki o'chiradi.