RASP — co to je, princip fungování a ochrana v reálném čase

Co je RASP?

Runtime Application Self-Protection (RASP) — bezpečnostní technologie integrovaná do aplikace ve fázi sestavení nebo prostřednictvím runtime agenta. RASP analyzuje chování aplikace během provádění a rozhoduje o blokování útoků na základě kontextu: odkud volání přišlo, jaká data jsou přenášena, jaký je stav zásobníku. Na rozdíl od signaturových systémů RASP nevyhledává známé vzorce útoků — detekuje anomální chování odchylující se od očekávaného scénáře provádění kódu.

Koncepce RASP byla formalizována společností Gartner v roce 2011 a první komerční implementace se objevily v letech 2014–2015. Pro mobilní platformy se RASP začal aktivně používat od roku 2017, kdy si trh uvědomil nedostatečnost tradiční obfuskace. Podle zprávy MarketsandMarkets (2025) činí objem trhu řešení RASP 2,8 miliardy USD s ročním růstem 24,5%. Zavedení RASP je doporučeno standardy OWASP Mobile Top 10 a PCI DSS 4.0 pro aplikace zpracovávající platební údaje.

RASP pracuje na dvou úrovních: interception a assessment. Interception — zachycování systémových a knihovních volání pomocí háčků vložených do kódu ve fázi sestavení nebo za běhu prostřednictvím dynamické instrumentace. Assessment — analýza kontextu volání: kontrola vstupních parametrů, zásobníku volání, stavu sandboxu, přítomnosti debuggeru. Rozhodnutí je učiněno na základě bezpečnostní politiky nastavené vývojářem. Politika může být přísná (blokovat), měkká (protokolovat) nebo adaptivní (měnit chování v závislosti na úrovni hrozby).

Jak RASP funguje: architektura a mechanismy

Architektura RASP agenta se skládá ze tří komponent: instrumentační vrstvy, analyzátoru a politiky. Instrumentační vrstva zachycuje systémová volání a volání frameworku. Analyzátor kontroluje kontext na shodu s očekávanými vzory. Politika určuje reakci.

Instrumentace kódu

Pro mobilní aplikace se používá instrumentace v době kompilace (compile-time): bytekód nebo nativní kód je upraven ve fázi sestavení — před každým nebezpečným voláním je vložena kontrola. Kompilátor RASP agenta upravuje vstupní body FileOutputStream.write(), Runtime.exec(), Class.forName() a android.app.Activity.onStart(). Pro Android se používá transformace DEX bytekódu prostřednictvím Gradle pluginu; pro iOS — úprava binárního souboru Mach-O pomocí post-link skriptu.

Analýza kontextu

Při zachycení volání RASP analyzuje: volající třídu a metodu (kdo volá), trasování zásobníku (řetězec volání), argumenty (přenášená data), návratovou hodnotu (co je vráceno), časové razítko a ID vlákna. Anomálie je zaznamenána, když je například Runtime.exec() voláno ne z UI vlákna a ne z kódu aplikace, ale z knihovny načtené přes JNI s nestandardní cestou. Nebo když FileOutputStream.write() obdrží data obsahující spustitelný bytekód místo očekávané hlavičky PNG.

Politiky reakce

RASP podporuje tři typy reakce: Block — nouzové ukončení aplikace při detekci útoku, Log — odeslání podrobností incidentu na server pro sběr logů bez zastavení aplikace, Deceive — nahrazení návratové hodnoty falešnou, aby útočník obdržel nesprávná data. Kombinace Log a Deceive umožňuje sbírat zpravodajské informace o útočníkovi, aniž by byl odhalen fakt detekce.

// Příklad: RASP kontrola volání Runtime.exec()
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // Kontrola volajícího
        String caller = stack[1].getClassName();

        // Pokud volání nepochází z našeho balíčku — podezřelé
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Kontrola příkazu na černé listině
        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: prázdný proces
            }
        }

        return null; // povolit provedení
    }
}

RASP vs WAF a další ochranné prostředky

RASP je často srovnáván s Web Application Firewall (WAF), ale zásadní rozdíl spočívá v umístění. WAF se nachází na perimetru sítě a analyzuje pouze HTTP požadavky. RASP pracuje uvnitř aplikace a vidí logiku zpracování.

Na rozdíl od obfuskace (ProGuard, DexGuard), která činí kód nečitelným, RASP aktivně detekuje útoky během zneužívání. Obfuskace je pasivní ochrana: pokud útočník věnuje dostatek času reverznímu inženýrství, kód bude přečten. RASP je aktivní: vidí, že se útočník pokouší ladit aplikaci, a reaguje dříve, než je přečten byť jen jeden řádek kódu. Kombinace obfuskace + RASP poskytuje vícevrstvou ochranu, kde obfuskace zpomaluje analýzu a RASP přerušuje útok ve fázi instrumentace.

RASP v mobilních aplikacích

Mobilní řešení RASP jsou přizpůsobena specifikům Androidu a iOS. Na rozdíl od serverových Java aplikací pracují mobilní RASP agenti v podmínkách omezené paměti a baterie, což vyžaduje lehkou instrumentaci.

RASP na Androidu

Na Androidu je RASP agent vložen prostřednictvím Gradle pluginu, který upravuje DEX bytekód ve fázi sestavení. Agent zachycuje více než 50 systémových volání, včetně: Runtime.exec() pro detekci spuštění su nebo Frida, Class.forName() pro identifikaci načítání podezřelých tříd, System.loadLibrary() pro kontrolu načítání nativních knihoven z nestandardních cest. Dále se kontroluje přítomnost v /proc/self/maps knihoven frida-agent, frida-helper, libinject a substrate.

RASP na iOS

Na iOS je RASP implementován prostřednictvím následného zpracování binárního souboru Mach-O. Pro iOS je složitost vyšší kvůli přísným požadavkům Apple na úpravu binárních souborů. Agent zachycuje volání funkcí fork(), dlopen(), ptrace() a kontroluje přítomnost CydiaSubstrate.dylib v načtených knihovnách. RASP pro iOS nemůže upravovat kód v sestavení App Store — pouze pro Enterprise distribuci. Pro App Store se doporučuje použití instrumentace v době kompilace prostřednictvím Swift Macro nebo Objective-C method swizzling.

Detekce analytických nástrojů

Mobilní RASP detekuje: Frida (prostřednictvím kontroly /proc/self/maps a /data/local/tmp/frida*), Xposed Framework (prostřednictvím kontroly de.robv.android.xposed.XposedBridge v ClassLoader), JDWP debugger (prostřednictvím Debug.isDebuggerConnected()), emulátory (prostřednictvím kontroly Build.FINGERPRINT, Build.HARDWARE, Build.MODEL) a příznak debuggable v AndroidManifest. Podle NowSecure Mobile Threat Report (2025) detekuje RASP agent 89–97% instrumentovaných relací Frida.

Implementace RASP agenta v praxi

Zavedení RASP do mobilní aplikace vyžaduje konfiguraci instrumentace, definici politik a integraci se systémem SIEM pro sběr logů incidentů.

Výběr implementace: compile-time vs runtime

Instrumentace v době kompilace (compile-time) — úprava bytekódu ve fázi sestavení, která neovlivňuje výkon za běhu. Instrumentace za běhu (runtime) (prostřednictvím Java Agent na serveru nebo Frida na klientovi) — flexibilnější, ale přidává 5–10% režii. Pro mobilní aplikace se doporučuje přístup compile-time, protože nevyžaduje trvalé připojení k síti a nespotřebovává baterii na analýzu.

Integrace se stávajícími knihovnami

RASP agent musí správně fungovat s populárními SDK. Firebase Crashlytics, Google Analytics a Appsee nesmí být blokovány. Konfigurace whitelistu pro známé knihovny je povinná. V konfiguraci agenta jsou stanoveny výjimky: pokud volání pochází z třídy com.google.firebase — kontrola se přeskočí. Whitelist je aktualizován s každým vydáním SDK.

Příklad zpracování incidentu

Při detekci Frida RASP agentem dochází k: shromáždění kontextu (trasování zásobníku, verze OS, čas), odeslání dat na logovací server v šifrované podobě, provedení politiky (crash, log-only nebo deceive), zvýšení čítače pro určení hromadného útoku. Data z různých zařízení jsou agregována na serveru pro identifikaci vzorců útoků.

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

Omezení a falešné poplachy

RASP není stříbrná kulka. Technologie má omezení, která je třeba zohlednit při navrhování ochrany.

Výkon

Každé zachycené volání přidává kontrolu kontextu. Při agresivní konfiguraci (zachycení všech IO a exec volání) může výkon klesnout o 5–15%. Pro mobilní aplikace je kritická doba spouštění: inicializace RASP přidává 200–500 ms při startu. Doporučuje se bodová instrumentace — pouze kritické funkce, ne všechny možné funkce. Profilování s RASP agentem je povinné ve fázi testování.

Falešné poplachy

RASP může blokovat legitimní chování: Firebase Crashlytics odesílající zásobník chyb pomocí síťového volání může být považováno za exfiltraci dat; Google Play Integrity API kontrolující integritu zařízení může být identifikováno jako podezřelé volání. Pro snížení falešných poplachů je nutná doba učení (learning mode) v délce 7–14 dní, během které RASP pouze protokoluje, ale neblokuje.

Obcházení RASP

Pokud útočník získá přístup na úrovni jádra (prostřednictvím exploitu jádra), RASP nemůže důvěřovat ani vlastním kontrolám — agent pracuje v uživatelském prostoru a vidí to, co mu jádro povolí. K zabránění obcházení na úrovni jádra se používá kontrola Secure Boot Chain v kombinaci s atestací serveru. Kromě toho musí být samotný RASP agent obfuskován a chráněn proti ladění — jinak útočník RASP odstraní nebo deaktivuje před zahájením útoku.