Runtime Application Self-Protection (RASP): cos’è e come si implementa

Cos’è il RASP

Il RASP è un meccanismo di difesa integrato nel runtime dell’applicazione.

Non è un prodotto “esterno”, come un WAF, ma gira dentro il processo dell’applicazione stessa.
Intercetta chiamate e azioni sensibili (query al database, esecuzioni di comandi, chiamate a librerie di sistema, input/output dell’utente).
Analizza il contesto per capire se un’operazione è legittima o potenzialmente malevola (es. SQL injection, RCE, path traversal).
Può bloccare l’attacco, allertare i log e in alcuni casi anche autocorreggere l’esecuzione.

In sostanza, il RASP unisce application monitoring + intrusion prevention a livello di codice.

Come funziona tecnicamente

Ecco i principali approcci:

Instrumentation: il codice dell’app viene “strumentato” (con agenti o librerie) per intercettare funzioni critiche.
Hooking del runtime: il RASP si aggancia alle chiamate del linguaggio (es. metodi JDBC in Java, funzioni di parsing in .NET, esecuzioni di comandi in Node.js).
Analisi comportamentale: combina signature note con modelli di comportamento (es. “questa query non è tipica” → blocco).

Esempio: protezione contro SQL Injection

Immaginiamo un’applicazione Java che esegue query SQL:

Senzo RASP

String query = "SELECT * FROM utenti WHERE username = '" + userInput + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(query);

Un attaccante potrebbe inserire:

' OR '1'='1

e bypassare l’autenticazione.

Con RASP (logica semplificata)

Il RASP intercetta la query prima dell’esecuzione:

Analizza la stringa SQL.
Riconosce pattern sospetti (' OR '1'='1).
Blocca l’esecuzione o riscrive la query.

Pseudo-codice di un agente RASP:

public ResultSet safeExecuteQuery(String query) throws SecurityException {
    if (isMalicious(query)) {
        logAttack("SQL Injection attempt: " + query);
        throw new SecurityException("Blocked malicious SQL");
    }
    return realStatement.executeQuery(query);
}

private boolean isMalicious(String query) {
    // Riconosce tautologie o manipolazioni note
    return query.toLowerCase().contains(" or '1'='1") 
        || query.toLowerCase().matches(".*(--|;).*");
}

Implementazione pratica

Le aziende non scrivono un RASP da zero: si usano soluzioni già pronte, spesso agenti da integrare nel runtime. Alcuni esempi:

Contrast Security
Imperva RASP
Micro Focus Fortify
Sqreen (ora Datadog Application Security)

Passi tipici per l’integrazione

Installare l’agente: un jar/agent (Java), una libreria .NET, o un middleware per Node.js.
Configurare le policy: cosa loggare, cosa bloccare.
Test in staging: osservare falsi positivi e aggiustare.
Deployment in produzione: il RASP gira “dentro” l’app, senza necessità di modifiche al codice nella maggior parte dei casi.

Esempio pratico: integrazione di Contrast Security Java agent in una Spring Boot app

1. Prerequisiti

- App Spring Boot (jar eseguibile).
- Account Contrast (o Community Edition) per scaricare l’agent e ottenere le credenziali.
(Contrast fornisce un agent “drop-in” che strumenta la JVM e raccoglie dati runtime).

2. Scarica l’agent

Dalla console Contrast scarichi il file contrast.jar (o contrast-agent.jar) o lo ottieni via Maven come indicato nella doc.

3. Avvia l'app con l'agent

Esempio: la tua app è app.jar, il jar agent è /opt/contrast/contrast.jar:

java -javaagent:/opt/contrast/contrast.jar -jar app.jar

Oppure, se vuoi passare parametri di configurazione (es. url del server Contrast, token), segui le indicazioni della console Contrast — spesso si impostano variabili d’ambiente o argomenti JVM.

4. Configurazione iniziale

Nell’interfaccia Contrast aggiungi l’app (Add Agent) e scarichi/ottieni le credenziali.
L’agent automaticamente inizia a monitorare richieste, flussi di dati sensibili e vulnerabilità in runtime; puoi attivare modalità di blocking o solo monitoring durante il testing.

5. Test pratico (SQLi)

Supponiamo un endpoint vulnerabile /login che accetta username e password. Test manuale con curl:

curl -X POST http://localhost:8080/login \
  -d "username=admin' OR '1'='1&password=whatever"

Cosa succede quando l’agent è attivo:

L’agent rileva pattern sospetto / flusso dati che corrisponde a SQLi.
In modalità block, l’accesso viene bloccato; in modalità monitor viene loggata l’evidenza dell’attacco nella console Contrast.

6. Suggerimenti pratici + best practice

Test in staging: sempre mettere RASP in monitoring prima di abilitare il blocco per ridurre falsi positivi. Onboarding graduale è la regola.
Metriche e overhead: misura CPU/latency perché l’instrumentation introduce overhead; dimensiona i nodi se necessario.
Logging & alerting: integra gli output del RASP nel tuo SIEM/monitoring per risposte rapide.
DevSecOps: usa i risultati del RASP per correggere il codice (non solo come banda di contenimento).

Consiglio pratico: quando metti in produzione un agent RASP, attiva prima la modalità 'monitor' e raccogli segnali per almeno qualche giorno/una settimana (dipende dal traffico) per calibrare le regole e minimizzare falsi positivi. Solo dopo puoi passare a politiche di blocking selettive per classi di attacco well-known (es. SQLi, RCE).

Vantaggi e limiti

✅ Vantaggi

Protezione immediata contro exploit zero-day.
Contesto applicativo più ricco rispetto a un WAF.
Deployment relativamente semplice (non richiede modifiche infrastrutturali).

⚠️ Limiti

Possibili overhead di performance.
Rischio di falsi positivi.
Non sostituisce lo sviluppo sicuro (DevSecOps).

Conclusione

Il Runtime Application Self-Protection non è la bacchetta magica, ma rappresenta un tassello fondamentale della difesa in profondità. Integrando il RASP, un’applicazione non si limita a “subire” i controlli esterni, ma acquisisce la capacità di difendersi autonomamente durante l’esecuzione.

Techelopment

Cerca nel blog