RASP — co to jest, zasada działania i ochrona w czasie rzeczywistym

Co to jest RASP?

Runtime Application Self-Protection (RASP) — technologia bezpieczeństwa integrowana z aplikacją na etapie budowania lub poprzez agenta czasu wykonania. RASP analizuje zachowanie aplikacji podczas działania i podejmuje decyzje o blokowaniu ataków na podstawie kontekstu: skąd pochodzi wywołanie, jakie dane są przekazywane, jaki jest stan stosu. W przeciwieństwie do systemów sygnaturowych, RASP nie szuka znanych wzorców ataków — wykrywa anormalne zachowanie odbiegające od oczekiwanego scenariusza wykonania kodu.

Koncepcja RASP została sformalizowana przez Gartner w 2011 roku, a pierwsze komercyjne implementacje pojawiły się w latach 2014–2015. Dla platform mobilnych RASP zaczął być aktywnie stosowany od 2017 roku, kiedy rynek uświadomił sobie niewystarczalność tradycyjnej obfuskacji. Według raportu MarketsandMarkets (2025), wartość rynku rozwiązań RASP wynosi 2,8 mld USD przy rocznym wzroście 24,5%. Wdrożenie RASP jest zalecane przez standardy OWASP Mobile Top 10 i PCI DSS 4.0 dla aplikacji przetwarzających dane płatnicze.

RASP działa na dwóch poziomach: interception i assessment. Interception — przechwytywanie wywołań systemowych i bibliotecznych poprzez hooki wbudowywane w kod na etapie budowania lub w czasie wykonania przez dynamiczną instrumentację. Assessment — analiza kontekstu wywołania: sprawdzanie parametrów wejściowych, stosu wywołań, stanu sandboxa, obecności debuggera. Decyzja jest podejmowana na podstawie polityki bezpieczeństwa określonej przez programistę. Polityka może być sztywna (blokuj), miękka (loguj) lub adaptacyjna (zmieniaj zachowanie w zależności od poziomu zagrożenia).

Jak działa RASP: architektura i mechanizmy

Architektura agenta RASP składa się z trzech komponentów: warstwy instrumentacji, analizatora i polityki. Warstwa instrumentacji przechwytuje wywołania systemowe i wywołania frameworka. Analizator sprawdza kontekst pod kątem zgodności z oczekiwanymi wzorcami. Polityka określa reakcję.

Instrumentacja kodu

Dla aplikacji mobilnych stosuje się instrumentację w czasie kompilacji (compile-time): bajtkod lub kod natywny jest modyfikowany na etapie budowania — przed każdym niebezpiecznym wywołaniem wstawiana jest kontrola. Kompilator agenta RASP modyfikuje punkty wejścia FileOutputStream.write(), Runtime.exec(), Class.forName() oraz android.app.Activity.onStart(). Dla Androida stosuje się transformację DEX-bajtkodu przez Gradle plugin; dla iOS — modyfikację binarnego pliku Mach-O przez skrypt post-link.

Analiza kontekstu

Podczas przechwytywania wywołania RASP analizuje: klasę i metodę wywołującą (kto wywołuje), ślad stosu (łańcuch wywołań), argumenty (przekazywane dane), wartość zwracaną (co jest zwracane), znacznik czasu i identyfikator wątku. Anomalia jest rejestrowana, gdy na przykład Runtime.exec() jest wywoływane nie z wątku UI i nie z kodu aplikacji, ale z biblioteki załadowanej przez JNI z niestandardową ścieżką. Lub gdy FileOutputStream.write() otrzymuje dane zawierające wykonywalny bajtkod zamiast oczekiwanego nagłówka PNG.

Polityki reagowania

RASP obsługuje trzy typy reagowania: Block — awaryjne zakończenie aplikacji po wykryciu ataku, Log — wysłanie szczegółów incydentu na serwer zbierania logów bez zatrzymywania aplikacji, Deceive — podmiana zwracanej wartości na fałszywą, aby atakujący otrzymał nieprawidłowe dane. Połączenie Log i Deceive pozwala zbierać dane wywiadowcze o atakującym, nie ujawniając faktu wykrycia.

// Przykład: Sprawdzenie wywołania Runtime.exec() przez RASP
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

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

        // Jeśli wywołanie nie pochodzi z naszego pakietu — podejrzane
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Sprawdzenie komendy na czarnej liście
        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: pusty proces
            }
        }

        return null; // zezwól na wykonanie
    }
}

RASP vs WAF i inne środki ochrony

RASP jest często porównywany z Web Application Firewall (WAF), ale zasadnicza różnica polega na pozycjonowaniu. WAF znajduje się na obrzeżach sieci i analizuje tylko żądania HTTP. RASP działa wewnątrz aplikacji i widzi logikę przetwarzania.

W przeciwieństwie do obfuskacji (ProGuard, DexGuard), która sprawia, że kod jest nieczytelny, RASP aktywnie wykrywa ataki w trakcie eksploatacji. Obfuskacja to ochrona pasywna: jeśli atakujący poświęci wystarczająco dużo czasu na inżynierię wsteczną, kod zostanie odczytany. RASP jest aktywny: widzi, że atakujący próbuje debugować aplikację i reaguje, zanim zostanie odczytana choćby jedna linia kodu. Połączenie obfuskacji i RASP daje wielowarstwową ochronę, gdzie obfuskacja spowalnia analizę, a RASP przerywa atak na etapie instrumentacji.

RASP w aplikacjach mobilnych

Mobilne rozwiązania RASP są dostosowane do specyfiki Androida i iOS. W przeciwieństwie do serwerowych aplikacji Java, mobilne agenty RASP działają w warunkach ograniczonej pamięci i baterii, co wymaga lekkiej instrumentacji.

RASP na Androidzie

Na Androidzie agent RASP jest wbudowywany przez Gradle plugin modyfikujący DEX-bajtkod na etapie budowania. Agent przechwytuje ponad 50 wywołań systemowych, w tym: Runtime.exec() do wykrywania uruchamiania su lub Frida, Class.forName() do identyfikowania ładowania podejrzanych klas, System.loadLibrary() do kontroli ładowania bibliotek natywnych z niestandardowych ścieżek. Dodatkowo sprawdzana jest obecność w /proc/self/maps bibliotek frida-agent, frida-helper, libinject i substrate.

RASP na iOS

Na iOS RASP jest implementowany przez post-processowanie binarnego pliku Mach-O. Dla iOS złożoność jest wyższa ze względu na surowe wymagania Apple dotyczące modyfikacji plików binarnych. Agent przechwytuje wywołania funkcji fork(), dlopen(), ptrace() i sprawdza obecność CydiaSubstrate.dylib w załadowanych bibliotekach. RASP dla iOS nie może modyfikować kodu w buildzie App Store — tylko dla dystrybucji Enterprise. Dla App Store zaleca się stosowanie instrumentacji w czasie kompilacji przez Swift Macro lub Objective-C method swizzling.

Wykrywanie narzędzi analitycznych

Mobilny RASP wykrywa: Frida (poprzez sprawdzenie /proc/self/maps i /data/local/tmp/frida*), Xposed Framework (poprzez sprawdzenie de.robv.android.xposed.XposedBridge w ClassLoader), debugger JDWP (poprzez Debug.isDebuggerConnected()), emulatory (poprzez sprawdzenie Build.FINGERPRINT, Build.HARDWARE, Build.MODEL) i flagę debuggable w AndroidManifest. Według danych NowSecure Mobile Threat Report (2025), agent RASP wykrywa 89–97% sesji Frida z instrumentacją.

Implementacja agenta RASP w praktyce

Wdrożenie RASP w aplikacji mobilnej wymaga skonfigurowania instrumentacji, określenia polityk i integracji z systemem SIEM do zbierania logów incydentów.

Wybór implementacji: compile-time vs runtime

Instrumentacja w czasie kompilacji (compile-time) — modyfikacja bajtkodu na etapie budowania, nie wpływająca na wydajność w czasie wykonania. Instrumentacja w czasie wykonania (runtime) (przez Java Agent na serwerze lub Frida na kliencie) — bardziej elastyczna, ale dodaje 5–10% narzutu. Dla aplikacji mobilnych zaleca się podejście compile-time, ponieważ nie wymaga stałego połączenia z siecią i nie zużywa baterii na analizę.

Integracja z istniejącymi bibliotekami

Agent RASP musi poprawnie współpracować z popularnymi SDK. Firebase Crashlytics, Google Analytics i Appsee nie powinny być blokowane. Konfiguracja whitelist dla znanych bibliotek jest obowiązkowa. W konfiguracji agenta określa się wyjątki: jeśli wywołanie pochodzi z klasy com.google.firebase — kontrola jest pomijana. Whitelist jest aktualizowany z każdym wydaniem SDK.

Przykład obsługi incydentu

Po wykryciu Fridy przez agenta RASP następuje: zebranie kontekstu (ślad stosu, wersja OS, czas), wysłanie danych na serwer logowania w zaszyfrowanej formie, wykonanie polityki (crash, log-only lub deceive), zwiększenie licznika w celu określenia masowego ataku. Dane z różnych urządzeń są agregowane na serwerze w celu identyfikacji wzorców ataków.

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

Ograniczenia i fałszywe alarmy

RASP nie jest srebrną kulą. Technologia ma ograniczenia, które należy uwzględnić przy projektowaniu ochrony.

Wydajność

Każde przechwycone wywołanie dodaje sprawdzenie kontekstu. Przy agresywnej konfiguracji (przechwytywanie wszystkich wywołań IO i exec) wydajność może spaść o 5–15%. Dla aplikacji mobilnych krytyczny jest czas uruchamiania: inicjalizacja RASP dodaje 200–500 ms na starcie. Zaleca się punktową instrumentację — tylko krytyczne funkcje, a nie wszystkie możliwe. Profilowanie z agentem RASP jest obowiązkowe na etapie testowania.

Fałszywe alarmy

RASP może blokować legalne zachowanie: Firebase Crashlytics wysyłająca stos błędów przez wywołanie sieciowe może zostać uznana za eksfiltrację danych; Google Play Integrity API sprawdzające integralność urządzenia może zostać zidentyfikowane jako podejrzane wywołanie. Aby zmniejszyć liczbę fałszywych alarmów, niezbędny jest okres uczenia (learning mode) trwający 7–14 dni, podczas którego RASP tylko loguje, ale nie blokuje.

Ominnięcie RASP

Jeśli atakujący uzyska dostęp na poziomie jądra (poprzez exploit jądra), RASP nie może ufać nawet własnym kontrolom — agent działa w przestrzeni użytkownika i widzi to, na co pozwala mu jądro. Aby zapobiec ominięciu na poziomie jądra, stosuje się sprawdzanie Secure Boot Chain w połączeniu z atestacją serwerową. Ponadto sam agent RASP musi być zaciemniony i chroniony przed debugowaniem — w przeciwnym razie atakujący usunie lub wyłączy RASP przed rozpoczęciem ataku.