RASP — ce este, principiul de funcționare și protecția în timp real

Ce este RASP?

Runtime Application Self-Protection (RASP) — tehnologie de securitate integrată în aplicație în faza de compilare sau printr-un agent de runtime. RASP analizează comportamentul aplicației în timpul execuției și ia decizii privind blocarea atacurilor pe baza contextului: de unde provine apelul, ce date sunt transmise, care este starea stivei. Spre deosebire de sistemele cu semnături, RASP nu caută modele cunoscute de atacuri — detectează comportamentul anormal care deviază de la scenariul așteptat de execuție a codului.

Conceptul RASP a fost formalizat de Gartner în 2011, iar primele implementări comerciale au apărut în 2014–2015. Pentru platformele mobile, RASP a început să fie aplicat activ din 2017, când piața a conștientizat insuficiența ofuscării tradiționale. Conform raportului MarketsandMarkets (2025), volumul pieței soluțiilor RASP este de 2,8 miliarde USD cu o creștere anuală de 24,5%. Implementarea RASP este recomandată de standardele OWASP Mobile Top 10 și PCI DSS 4.0 pentru aplicațiile care procesează date de plată.

RASP funcționează la două niveluri: interception și assessment. Interception — interceptarea apelurilor de sistem și de bibliotecă prin hookuri încorporate în cod în faza de compilare sau în runtime prin instrumentare dinamică. Assessment — analiza contextului apelului: verificarea parametrilor de intrare, a stivei de apeluri, a stării sandbox-ului, a prezenței debuggerului. Decizia este luată pe baza politicii de securitate stabilită de dezvoltator. Politica poate fi rigidă (blochează), moale (înregistrează) sau adaptivă (modifică comportamentul în funcție de nivelul amenințării).

Cum funcționează RASP: arhitectură și mecanisme

Arhitectura agentului RASP este formată din trei componente: stratul de instrumentare, analizatorul și politica. Stratul de instrumentare interceptează apelurile de sistem și apelurile framework-ului. Analizatorul verifică contextul pentru conformitatea cu modelele așteptate. Politica determină reacția.

Instrumentarea codului

Pentru aplicațiile mobile se utilizează instrumentarea la compilare (compile-time): bytecodul sau codul nativ este modificat în faza de compilare — înainte de fiecare apel periculos este inserată o verificare. Compilatorul agentului RASP modifică punctele de intrare FileOutputStream.write(), Runtime.exec(), Class.forName() și android.app.Activity.onStart(). Pentru Android se utilizează transformarea bytecodului DEX prin Gradle plugin; pentru iOS — modificarea binarului Mach-O prin scriptul post-link.

Analiza contextului

La interceptarea apelului, RASP analizează: clasa și metoda apelantă (cine apelează), urma stivei (lanțul de apeluri), argumentele (datele transmise), valoarea returnată (ce se returnează), marca temporală și id-ul firului de execuție. Anomalia este înregistrată când, de exemplu, Runtime.exec() este apelat nu din firul UI și nici din codul aplicației, ci dintr-o bibliotecă încărcată prin JNI cu o cale nestandard. Sau când FileOutputStream.write() primește date care conțin bytecod executabil în locul unui antet PNG așteptat.

Politici de reacție

RASP suportă trei tipuri de reacție: Block — terminarea de urgență a aplicației la detectarea atacului, Log — trimiterea detaliilor incidentului la serverul de colectare a logurilor fără oprirea aplicației, Deceive — înlocuirea valorii returnate cu una falsă, astfel încât atacatorul să primească date incorecte. Combinația Log și Deceive permite colectarea de informații despre atacator fără a dezvălui faptul detectării.

// Exemplu: Verificarea apelului Runtime.exec() de către RASP
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

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

        // Dacă apelul nu provine din pachetul nostru — suspect
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Verificarea comenzii pe lista neagră
        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: proces gol
            }
        }

        return null; // permite executarea
    }
}

RASP vs WAF și alte mijloace de protecție

RASP este adesea comparat cu Web Application Firewall (WAF), dar diferența fundamentală constă în poziționare. WAF se află la perimetrul rețelei și analizează doar cererile HTTP. RASP funcționează în interiorul aplicației și vede logica de procesare.

Spre deosebire de ofuscare (ProGuard, DexGuard), care face codul ilizibil, RASP detectează activ atacurile în timpul exploatării. Ofuscarea este o protecție pasivă: dacă atacatorul petrece suficient timp pentru inginerie inversă, codul va fi citit. RASP este activ: el vede că atacatorul încearcă să depaneze aplicația și reacționează înainte ca măcar o linie de cod să fie citită. Combinația ofuscare + RASP oferă o protecție multistratificată, unde ofuscarea încetinește analiza, iar RASP întrerupe atacul în faza de instrumentare.

RASP în aplicațiile mobile

Soluțiile RASP mobile sunt adaptate specificului Android și iOS. Spre deosebire de aplicațiile server Java, agenții RASP mobili funcționează în condiții de memorie și baterie limitate, ceea ce necesită o instrumentare ușoară.

RASP pe Android

Pe Android, agentul RASP este încorporat prin Gradle plugin care modifică bytecodul DEX în faza de compilare. Agentul interceptează peste 50 de apeluri de sistem, inclusiv: Runtime.exec() pentru detectarea lansării su sau Frida, Class.forName() pentru identificarea încărcării claselor suspecte, System.loadLibrary() pentru controlul încărcării bibliotecilor native din căi nestandard. În plus, se verifică prezența în /proc/self/maps a bibliotecilor frida-agent, frida-helper, libinject și substrate.

RASP pe iOS

Pe iOS, RASP este implementat prin post-procesarea binarului Mach-O. Pentru iOS complexitatea este mai mare din cauza cerințelor stricte Apple privind modificarea binarilor. Agentul interceptează apelurile funcțiilor fork(), dlopen(), ptrace() și verifică prezența CydiaSubstrate.dylib în bibliotecile încărcate. RASP pentru iOS nu poate modifica codul în build-ul App Store — doar pentru distribuția Enterprise. Pentru App Store se recomandă utilizarea instrumentării la compilare prin Swift Macro sau Objective-C method swizzling.

Detectarea instrumentelor de analiză

RASP mobil detectează: Frida (prin verificarea /proc/self/maps și /data/local/tmp/frida*), Xposed Framework (prin verificarea de.robv.android.xposed.XposedBridge în ClassLoader), debuggerul JDWP (prin Debug.isDebuggerConnected()), emulatoarele (prin verificarea Build.FINGERPRINT, Build.HARDWARE, Build.MODEL) și flag-ul debuggable din AndroidManifest. Conform datelor NowSecure Mobile Threat Report (2025), agentul RASP detectează 89–97% din sesiunile instrumentate Frida.

Implementarea agentului RASP în practică

Implementarea RASP într-o aplicație mobilă necesită configurarea instrumentării, definirea politicilor și integrarea cu sistemul SIEM pentru colectarea logurilor de incidente.

Alegerea implementării: compile-time vs runtime

Instrumentarea la compilare (compile-time) — modificarea bytecodului în faza de compilare, care nu afectează performanța în runtime. Instrumentarea în runtime (prin Java Agent pe server sau Frida pe client) — mai flexibilă, dar adaugă 5–10% suprasarcină. Pentru aplicațiile mobile se recomandă abordarea compile-time, deoarece nu necesită conexiune permanentă la rețea și nu consumă baterie pentru analiză.

Integrarea cu bibliotecile existente

Agentul RASP trebuie să funcționeze corect cu SDK-urile populare. Firebase Crashlytics, Google Analytics și Appsee nu trebuie blocate. Configurarea whitelist pentru bibliotecile cunoscute este obligatorie. În configurația agentului se stabilesc excepții: dacă apelul provine din clasa com.google.firebase — verificarea este omisă. Whitelist este actualizat cu fiecare lansare de SDK.

Exemplu de procesare a incidentului

La detectarea Frida de către agentul RASP are loc: colectarea contextului (urma stivei, versiunea OS, timpul), trimiterea datelor la serverul de logging în formă criptată, executarea politicii (crash, log-only sau deceive), incrementarea contorului pentru determinarea atacului în masă. Datele de pe diferite dispozitive sunt agregate pe server pentru identificarea modelelor de atac.

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

Limitări și alarme false

RASP nu este un glonț de argint. Tehnologia are limitări care trebuie luate în considerare la proiectarea protecției.

Performanță

Fiecare apel interceptat adaugă o verificare a contextului. La o configurație agresivă (interceptarea tuturor apelurilor IO și exec), performanța poate scădea cu 5–15%. Pentru aplicațiile mobile, timpul de pornire este critic: inițializarea RASP adaugă 200–500 ms la pornire. Se recomandă instrumentarea punctuală — doar funcțiile critice, nu toate funcțiile posibile. Profilarea cu agentul RASP este obligatorie în faza de testare.

Alarme false

RASP poate bloca comportamentul legitim: Firebase Crashlytics care trimite stiva de erori printr-un apel de rețea poate fi considerată exfiltrare de date; Google Play Integrity API care verifică integritatea dispozitivului poate fi identificat ca un apel suspect. Pentru reducerea alarmelor false este necesară o perioadă de învățare (learning mode) de 7–14 zile, în care RASP doar înregistrează, dar nu blochează.

Ocolirea RASP

Dacă atacatorul obține acces la nivel de kernel (printr-un exploit de kernel), RASP nu poate avea încredere nici măcar în propriile verificări — agentul funcționează în spațiul utilizatorului și vede ceea ce kernel-ul îi permite. Pentru prevenirea ocolirii la nivel de kernel se utilizează verificarea Secure Boot Chain în combinație cu atestarea serverului. În plus, agentul RASP însuși trebuie ofuscat și protejat împotriva depanării — altfel atacatorul va elimina sau dezactiva RASP înainte de a începe atacul.