RASP — cos’è, principio di funzionamento e protezione in tempo reale

Cos’è RASP?

Runtime Application Self-Protection (RASP) è una tecnologia di sicurezza integrata nell’applicazione durante la compilazione o tramite un agente runtime. RASP analizza il comportamento dell’applicazione durante l’esecuzione e prende decisioni per bloccare gli attacchi in base al contesto: da dove proviene la chiamata, quali dati vengono trasmessi, qual è lo stato dello stack. A differenza dei sistemi basati su firme, RASP non cerca modelli di attacco noti — rileva comportamenti anomali che si discostano dallo scenario di esecuzione previsto.

Il concetto di RASP è stato formalizzato da Gartner nel 2011, e le prime implementazioni commerciali sono apparse nel 2014–2015. Per le piattaforme mobili, RASP ha iniziato a essere utilizzato attivamente nel 2017, quando il mercato ha compreso l’insufficienza dell’offuscamento tradizionale. Secondo un rapporto di MarketsandMarkets (2025), il mercato delle soluzioni RASP vale 2,8 miliardi di USD con una crescita annuale del 24,5%. L’implementazione di RASP è raccomandata dagli standard OWASP Mobile Top 10 e PCI DSS 4.0 per le applicazioni che elaborano dati di pagamento.

RASP opera su due livelli: intercettazione e valutazione. L’intercettazione è l’hook delle chiamate di sistema e di libreria tramite hook incorporati nel codice durante la compilazione o in runtime tramite strumentazione dinamica. La valutazione è l’analisi del contesto della chiamata: verifica dei parametri di input, stack delle chiamate, stato della sandbox, presenza del debugger. La decisione viene presa in base alla politica di sicurezza impostata dallo sviluppatore. La politica può essere rigida (bloccare), morbida (registrare) o adattiva (modificare il comportamento in base al livello di minaccia).

Come funziona RASP: architettura e meccanismi

L’architettura dell’agente RASP è composta da tre componenti: livello di strumentazione, analizzatore e politica. Il livello di strumentazione intercetta le chiamate di sistema e del framework. L’analizzatore verifica il contesto rispetto ai modelli previsti. La politica determina la risposta.

Strumentazione del codice

Per le applicazioni mobili viene utilizzata la strumentazione in fase di compilazione: il bytecode o il codice nativo viene modificato durante la compilazione — viene inserito un controllo prima di ogni chiamata pericolosa. Il compilatore dell’agente RASP modifica i punti di ingresso FileOutputStream.write(), Runtime.exec(), Class.forName() e android.app.Activity.onStart(). Per Android viene utilizzata la trasformazione del bytecode DEX tramite plugin Gradle; per iOS, la modifica del binario Mach-O tramite script post-link.

Analisi del contesto

Quando intercetta una chiamata, RASP analizza: classe e metodo chiamante (chi sta chiamando), stack trace (catena di chiamate), argomenti (dati trasmessi), valore di ritorno (cosa viene restituito), timestamp e id del thread. Un’anomalia viene registrata quando, ad esempio, Runtime.exec() viene chiamato non dal thread UI e non dal codice dell’applicazione, ma da una libreria caricata tramite JNI con un percorso non standard. O quando FileOutputStream.write() riceve dati contenenti bytecode eseguibile invece dell’intestazione PNG prevista.

Politiche di risposta

RASP supporta tre tipi di risposta: Block — arresto forzato dell’applicazione al rilevamento di un attacco, Log — invio dei dettagli dell’incidente al server di raccolta log senza fermare l’applicazione, Deceive — sostituzione del valore di ritorno con uno falso in modo che l’attaccante riceva dati errati. La combinazione di Log e Deceive consente di raccogliere informazioni sull’attaccante senza rivelare il fatto del rilevamento.

// Esempio: controllo RASP della chiamata Runtime.exec()
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

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

        // Se la chiamata non proviene dal nostro pacchetto — sospetto
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Controllo comando contro la lista nera
        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: processo vuoto
            }
        }

        return null; // consenti esecuzione
    }
}

RASP vs WAF e altri strumenti di sicurezza

RASP viene spesso confrontato con il Web Application Firewall (WAF), ma la differenza fondamentale risiede nel posizionamento. Il WAF si trova alla periferia della rete e analizza solo le richieste HTTP. RASP opera all’interno dell’applicazione e vede la logica di elaborazione.

A differenza dell’offuscamento (ProGuard, DexGuard), che rende il codice illeggibile, RASP rileva attivamente gli attacchi durante lo sfruttamento. L’offuscamento è una protezione passiva: se l’attaccante dedica abbastanza tempo al reverse engineering, il codice verrà letto. RASP è attivo: vede che l’attaccante sta cercando di eseguire il debug dell’applicazione e risponde prima che venga letta anche una singola riga di codice. La combinazione di offuscamento + RASP fornisce una protezione a più livelli, dove l’offuscamento rallenta l’analisi e RASP interrompe l’attacco nella fase di strumentazione.

RASP nelle applicazioni mobili

Le soluzioni RASP mobili sono adattate alle specificità di Android e iOS. A differenza delle applicazioni Java lato server, gli agenti RASP mobili operano con memoria e batteria limitate, richiedendo una strumentazione leggera.

RASP su Android

Su Android, l’agente RASP viene incorporato tramite un plugin Gradle che modifica il bytecode DEX durante la compilazione. L’agente intercetta oltre 50 chiamate di sistema, tra cui: Runtime.exec() per rilevare l’esecuzione di su o Frida, Class.forName() per identificare il caricamento di classi sospette, System.loadLibrary() per controllare il caricamento di librerie native da percorsi non standard. Inoltre, verifica in /proc/self/maps la presenza delle librerie frida-agent, frida-helper, libinject e substrate.

RASP su iOS

Su iOS, RASP viene implementato tramite post-elaborazione del binario Mach-O. iOS è più complesso a causa dei severi requisiti di Apple per la modifica dei binari. L’agente intercetta le chiamate alle funzioni fork(), dlopen(), ptrace() e verifica la presenza di CydiaSubstrate.dylib tra le librerie caricate. RASP per iOS non può modificare il codice nelle build dell’App Store — solo per la distribuzione Enterprise. Per l’App Store, si raccomanda la strumentazione in fase di compilazione tramite Swift Macro o method swizzling di Objective-C.

Rilevamento degli strumenti di analisi

Il RASP mobile rileva: Frida (tramite verifica di /proc/self/maps e /data/local/tmp/frida*), Xposed Framework (tramite verifica di de.robv.android.xposed.XposedBridge nel ClassLoader), debugger JDWP (tramite Debug.isDebuggerConnected()), emulatori (tramite verifica di Build.FINGERPRINT, Build.HARDWARE, Build.MODEL) e il flag debuggable in AndroidManifest. Secondo il NowSecure Mobile Threat Report (2025), un agente RASP rileva l’89–97% delle sessioni Frida strumentate.

Implementazione pratica di un agente RASP

L’integrazione di RASP in un’applicazione mobile richiede la configurazione della strumentazione, la definizione delle politiche e l’integrazione con un sistema SIEM per la raccolta dei log degli incidenti.

Scelta dell’implementazione: compile-time vs runtime

La strumentazione in fase di compilazione — modifica del bytecode durante la compilazione, non influisce sulle prestazioni runtime. La strumentazione in fase di esecuzione (tramite Java Agent sul server o Frida sul client) è più flessibile ma aggiunge un overhead del 5–10%. Per le applicazioni mobili, si raccomanda l’approccio in fase di compilazione, poiché non richiede una connessione di rete costante e non consuma batteria per l’analisi.

Integrazione con librerie esistenti

L’agente RASP deve funzionare correttamente con gli SDK popolari. Firebase Crashlytics, Google Analytics e Appsee non devono essere bloccati. La configurazione della whitelist per le librerie note è obbligatoria. Nella configurazione dell’agente vengono specificate le eccezioni: se una chiamata proviene dalla classe com.google.firebase — il controllo viene saltato. La whitelist viene aggiornata con ogni versione dell’SDK.

Esempio di gestione degli incidenti

Quando Frida viene rilevato tramite l’agente RASP, si verifica quanto segue: raccolta del contesto (stack trace, versione del SO, ora), invio dei dati al server di logging in forma crittografata, esecuzione della politica (crash, solo log o deceive), incremento di un contatore per identificare un attacco di massa. I dati da diversi dispositivi vengono aggregati sul server per identificare modelli di attacco.

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

Limitazioni e falsi positivi

RASP non è un proiettile d’argento. La tecnologia ha limitazioni che devono essere considerate quando si progetta la protezione.

Prestazioni

Ogni chiamata intercettata aggiunge un controllo del contesto. Con una configurazione aggressiva (intercettare tutte le chiamate IO ed exec), le prestazioni possono calare del 5–15%. Il tempo di avvio è critico per le applicazioni mobili: l’inizializzazione di RASP aggiunge 200–500 ms all’avvio. Si raccomanda una strumentazione mirata — solo le funzioni critiche, non tutte quelle possibili. La profilazione con l’agente RASP è obbligatoria durante i test.

Falsi positivi

RASP può bloccare comportamenti legittimi: Firebase Crashlytics che invia uno stack di errori tramite una chiamata di rete potrebbe essere scambiato per esfiltrazione di dati; l’API Google Play Integrity che verifica l’integrità del dispositivo potrebbe essere identificata come una chiamata sospetta. Per ridurre i falsi positivi, è necessario un periodo di modalità di apprendimento (learning mode) di 7–14 giorni, durante il quale RASP registra solo ma non blocca.

Bypass di RASP

Se un attaccante ottiene accesso a livello di kernel (tramite un exploit del kernel), RASP non può fidarsi nemmeno dei propri controlli — l’agente opera nello spazio utente e vede solo ciò che il kernel gli permette di vedere. Per prevenire il bypass a livello di kernel, viene utilizzata la verifica Secure Boot Chain in combinazione con l’attestazione del server. Inoltre, l’agente RASP stesso deve essere offuscato e protetto dal debugging — altrimenti l’attaccante rimuoverà o disabiliterà RASP prima di lanciare l’attacco.