RASP — mi ez, működési elv és valós idejű védelem

Mi az RASP?

Runtime Application Self-Protection (RASP) — az alkalmazásba az építési fázisban vagy runtime ágensen keresztül integrált biztonsági technológia. A RASP elemzi az alkalmazás viselkedését a végrehajtás során, és a kontextus alapján dönt a támadások blokkolásáról: honnan érkezett a hívás, milyen adatok kerülnek átadásra, mi a verem állapota. Az aláírás-alapú rendszerekkel ellentétben a RASP nem ismert támadási mintákat keres — a kód várható végrehajtási forgatókönyvétől eltérő rendellenes viselkedést észlel.

A RASP koncepciót a Gartner formalizálta 2011-ben, az első kereskedelmi megvalósítások pedig 2014–2015-ben jelentek meg. Mobil platformokon a RASP-t 2017-től kezdték aktívan alkalmazni, amikor a piac felismerte a hagyományos obfuszkáció elégtelenségét. A MarketsandMarkets (2025) jelentése szerint a RASP megoldások piacának volumene 2,8 milliárd USD, éves növekedése 24,5%. A RASP bevezetését az OWASP Mobile Top 10 és PCI DSS 4.0 szabványok ajánlják a fizetési adatokat feldolgozó alkalmazások számára.

A RASP két szinten működik: interception és assessment. Interception — a rendszer- és könyvtárhívások elfogása az építési fázisban vagy runtime-ban dinamikus instrumentációval a kódba épített horgokon keresztül. Assessment — a hívási kontextus elemzése: bemeneti paraméterek, hívási verem, sandbox állapot, hibakereső jelenlétének ellenőrzése. A döntés a fejlesztő által beállított biztonsági irányelv alapján történik. Az irányelv lehet szigorú (blokkolás), lágy (naplózás) vagy adaptív (viselkedés megváltoztatása a fenyegetettségi szinttől függően).

Hogyan működik a RASP: architektúra és mechanizmusok

A RASP ágens architektúrája három komponensből áll: instrumentációs rétegből, elemzőből és irányelvből. Az instrumentációs réteg elfogja a rendszerhívásokat és a keretrendszer hívásait. Az elemző ellenőrzi a kontextust a várt mintáknak való megfelelés szempontjából. Az irányelv határozza meg a reakciót.

Kód instrumentáció

A mobil alkalmazásokhoz compile-time instrumentációt használnak: a bájtkód vagy natív kód az építési fázisban módosul — minden veszélyes hívás elé egy ellenőrzés kerül beszúrásra. A RASP ágens fordítója módosítja a FileOutputStream.write(), Runtime.exec(), Class.forName() és android.app.Activity.onStart() belépési pontokat. Android esetén DEX bájtkód transzformációt használnak Gradle plugin segítségével; iOS esetén a Mach-O bináris fájl módosítását post-link szkripttel.

Kontextus elemzése

A hívás elfogásakor a RASP elemzi: a hívó osztályt és metódust (ki hív), a verem nyomvonalát (hívási lánc), az argumentumokat (átadott adatok), a visszatérési értéket (mi kerül visszaadásra), az időbélyeget és a szál azonosítóját. Anomália kerül rögzítésre, amikor például a Runtime.exec() nem az UI szálból és nem az alkalmazás kódjából kerül meghívásra, hanem egy nem szabványos útvonalon JNI-n keresztül betöltött könyvtárból. Vagy amikor a FileOutputStream.write() a várt PNG fejléc helyett végrehajtható bájtkódot tartalmazó adatokat kap.

Reakció irányelvek

A RASP három reakciótípust támogat: Block — az alkalmazás vészleállítása támadás észlelésekor, Log — az incidens részleteinek elküldése a naplógyűjtő szerverre az alkalmazás leállítása nélkül, Deceive — a visszatérési érték hamisra cserélése, hogy a támadó helytelen adatokat kapjon. A Log és Deceive kombinációja lehetővé teszi a támadóval kapcsolatos hírszerzési adatok gyűjtését anélkül, hogy az észlelés ténye kiderülne.

// Példa: Runtime.exec() hívás RASP ellenőrzése
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // Hívó ellenőrzése
        String caller = stack[1].getClassName();

        // Ha a hívás nem a mi csomagunkból származik — gyanús
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Parancs ellenőrzése feketelistán
        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: üres folyamat
            }
        }

        return null; // végrehajtás engedélyezése
    }
}

RASP vs WAF és más védelmi eszközök

A RASP-ot gyakran hasonlítják a Web Application Firewall (WAF) megoldáshoz, de az alapvető különbség a pozicionálásban van. A WAF a hálózat peremén helyezkedik el, és csak a HTTP kéréseket elemzi. A RASP az alkalmazáson belül működik, és látja a feldolgozási logikát.

Az obfuszkációval (ProGuard, DexGuard) ellentétben, ami olvashatatlanná teszi a kódot, a RASP aktívan észleli a támadásokat a kihasználás során. Az obfuszkáció passzív védelem: ha a támadó elegendő időt tölt a visszafejtéssel, a kód elolvasható lesz. A RASP aktív: látja, hogy a támadó megpróbálja hibakereséssel vizsgálni az alkalmazást, és reagál, mielőtt akár egyetlen kódsor is elolvasásra kerülne. Az obfuszkáció + RASP kombinációja többrétegű védelmet nyújt, ahol az obfuszkáció lassítja az elemzést, a RASP pedig megszakítja a támadást az instrumentációs fázisban.

RASP mobil alkalmazásokban

A mobil RASP megoldások az Android és iOS specifikumaihoz igazodnak. A szerver Java alkalmazásokkal ellentétben a mobil RASP ágensek korlátozott memória és akkumulátor körülményei között működnek, ami könnyű instrumentációt igényel.

RASP Androidon

Androidon a RASP ágens az építési fázisban a DEX bájtkódot módosító Gradle pluginen keresztül épül be. Az ágens több mint 50 rendszerhívást fog el, beleértve: Runtime.exec() a su vagy Frida indításának észlelésére, Class.forName() a gyanús osztályok betöltésének azonosítására, System.loadLibrary() a natív könyvtárak nem szabványos útvonalról történő betöltésének ellenőrzésére. Ezenkívül ellenőrzi a /proc/self/maps fájlban a frida-agent, frida-helper, libinject és substrate könyvtárak jelenlétét.

RASP iOS-en

iOS-en a RASP a Mach-O bináris fájl utófeldolgozásával valósul meg. iOS esetén a komplexitás magasabb az Apple bináris fájlok módosítására vonatkozó szigorú követelményei miatt. Az ágens elfogja a fork(), dlopen(), ptrace() függvények hívásait, és ellenőrzi a CydiaSubstrate.dylib jelenlétét a betöltött könyvtárakban. Az iOS RASP nem módosíthatja a kódot az App Store buildben — csak Enterprise terjesztéshez. Az App Store számára a compile-time instrumentáció használata javasolt Swift Macro vagy Objective-C method swizzling segítségével.

Analízis eszközök észlelése

A mobil RASP észleli: Frida (a /proc/self/maps és /data/local/tmp/frida* ellenőrzésén keresztül), Xposed Framework (a de.robv.android.xposed.XposedBridge ellenőrzésén keresztül a ClassLoader-ben), JDWP hibakereső (a Debug.isDebuggerConnected() segítségével), emulátorok (a Build.FINGERPRINT, Build.HARDWARE, Build.MODEL ellenőrzésén keresztül) és a debuggable jelzőt az AndroidManifest-ben. A NowSecure Mobile Threat Report (2025) szerint a RASP ágens a Frida munkamenetek 89–97%-át észleli.

RASP ágens gyakorlati megvalósítása

A RASP mobil alkalmazásba történő bevezetése az instrumentáció konfigurálását, az irányelvek meghatározását és SIEM rendszerrel való integrációt igényel az incidensnaplók gyűjtéséhez.

Megvalósítás kiválasztása: compile-time vs runtime

Compile-time instrumentáció — a bájtkód módosítása az építési fázisban, amely nem befolyásolja a runtime teljesítményt. Runtime instrumentáció (Java Agent segítségével a szerveren vagy Frida a kliensoldalon) — rugalmasabb, de 5–10% többletterhelést ad. Mobil alkalmazásokhoz a compile-time megközelítés javasolt, mivel nem igényel állandó hálózati kapcsolatot és nem fogyasztja az akkumulátort az elemzéshez.

Integráció meglévő könyvtárakkal

A RASP ágensnek helyesen kell működnie a népszerű SDK-kkal. A Firebase Crashlytics, Google Analytics és Appsee nem blokkolható. Az ismert könyvtárak whitelist konfigurációja kötelező. Az ágens konfigurációjában kivételek kerülnek meghatározásra: ha a hívás a com.google.firebase osztályból származik — az ellenőrzés átugrásra kerül. A Whitelist minden SDK kiadással frissül.

Példa incidens kezelésére

A RASP ágens általi Frida észlelésekor történik: kontextus gyűjtése (verem nyomvonal, OS verzió, idő), adatok titkosított formában történő elküldése a naplózó szerverre, az irányelv végrehajtása (crash, log-only vagy deceive), a számláló növelése a tömeges támadás meghatározásához. A különböző eszközökről származó adatok a szerveren kerülnek összesítésre a támadási minták azonosítása érdekében.

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

Korlátozások és téves riasztások

A RASP nem ezüstgolyó. A technológiának vannak korlátozásai, amelyeket figyelembe kell venni a védelem tervezésekor.

Teljesítmény

Minden elfogott hívás egy kontextusellenőrzést ad hozzá. Agresszív konfiguráció esetén (az összes IO és exec hívás elfogása) a teljesítmény 5–15%-kal csökkenhet. Mobil alkalmazások esetén az indítási idő kritikus: a RASP inicializálása 200–500 ms-t ad hozzá az induláskor. Pontszerű instrumentáció javasolt — csak a kritikus függvények, nem az összes lehetséges függvény. A Profilozás RASP ágenssel a tesztelési fázisban kötelező.

Téves riasztások

A RASP blokkolhatja a legitim viselkedést: a Firebase Crashlytics, amely hálózati híváson keresztül küldi a hibavermet, adatszivárgásként értékelhető; a Google Play Integrity API, amely ellenőrzi az eszköz integritását, gyanús hívásként azonosítható. A téves riasztások csökkentéséhez 7–14 napos tanulási időszakra (learning mode) van szükség, amely alatt a RASP csak naplóz, de nem blokkol.

A RASP megkerülése

Ha a támadó kernel szintű hozzáférést szerez (kernel exploit segítségével), a RASP még a saját ellenőrzéseiben sem bízhat — az ágens a felhasználói térben működik, és azt látja, amit a kernel enged. A kernel szintű megkerülés megakadályozásához Secure Boot Chain ellenőrzés használatos szerver tanúsítással kombinálva. Ezenkívül magának a RASP ágensnek is obfuszkáltnak és hibakeresés ellen védettnek kell lennie — különben a támadó eltávolítja vagy letiltja a RASP-ot a támadás megkezdése előtt.