RASP — ce que c’est, principe de fonctionnement et protection en temps réel

Qu’est-ce que RASP ?

Runtime Application Self-Protection (RASP) est une technologie de sécurité intégrée dans l’application lors de la compilation ou via un agent d’exécution. RASP analyse le comportement de l’application pendant l’exécution et prend des décisions pour bloquer les attaques en fonction du contexte : d’où vient l’appel, quelles données sont transmises, quel est l’état de la pile. Contrairement aux systèmes basés sur des signatures, RASP ne recherche pas de modèles d’attaque connus — il détecte les comportements anormaux qui s’écartent du scénario d’exécution attendu.

Le concept de RASP a été formalisé par Gartner en 2011, et les premières implémentations commerciales sont apparues en 2014–2015. Pour les plateformes mobiles, RASP a commencé à être activement utilisé en 2017, lorsque le marché a pris conscience de l’insuffisance de l’obfuscation traditionnelle. Selon un rapport de MarketsandMarkets (2025), le marché des solutions RASP s’élève à 2,8 milliards USD avec une croissance annuelle de 24,5 %. L’implémentation de RASP est recommandée par les normes OWASP Mobile Top 10 et PCI DSS 4.0 pour les applications traitant des données de paiement.

RASP fonctionne à deux niveaux : l’interception et l’évaluation. L’interception est le hooking des appels système et bibliothèques via des crochets intégrés dans le code lors de la compilation ou à l’exécution via l’instrumentation dynamique. L’évaluation est l’analyse du contexte d’appel : vérification des paramètres d’entrée, de la pile d’appels, de l’état du sandbox, de la présence du débogueur. La décision est prise en fonction de la politique de sécurité définie par le développeur. La politique peut être stricte (bloquer), souple (journaliser) ou adaptative (modifier le comportement selon le niveau de menace).

Comment fonctionne RASP : architecture et mécanismes

L’architecture de l’agent RASP se compose de trois composants : la couche d’instrumentation, l’analyseur et la politique. La couche d’instrumentation intercepte les appels système et les appels du framework. L’analyseur vérifie le contexte par rapport aux modèles attendus. La politique détermine la réponse.

Instrumentation du code

Pour les applications mobiles, l’instrumentation au moment de la compilation est utilisée : le bytecode ou le code natif est modifié lors de la compilation — une vérification est insérée avant chaque appel dangereux. Le compilateur de l’agent RASP modifie les points d’entrée FileOutputStream.write(), Runtime.exec(), Class.forName() et android.app.Activity.onStart(). Pour Android, la transformation du bytecode DEX est utilisée via le plugin Gradle ; pour iOS, la modification du binaire Mach-O via un script post-link.

Analyse du contexte

Lors de l’interception d’un appel, RASP analyse : la classe et la méthode appelante (qui appelle), la trace de pile (chaîne d’appels), les arguments (données transmises), la valeur de retour (ce qui est retourné), l’horodatage et l’identifiant du thread. Une anomalie est enregistrée lorsque, par exemple, Runtime.exec() est appelé non pas depuis le thread UI ni depuis le code de l’application, mais depuis une bibliothèque chargée via JNI avec un chemin non standard. Ou lorsque FileOutputStream.write() reçoit des données contenant du bytecode exécutable au lieu de l’en-tête PNG attendu.

Politiques de réponse

RASP prend en charge trois types de réponse : Block — arrêt forcé de l’application lors de la détection d’une attaque, Log — envoi des détails de l’incident au serveur de collecte de journaux sans arrêter l’application, Deceive — remplacement de la valeur de retour par une valeur fausse afin que l’attaquant reçoive des données incorrectes. La combinaison de Log et Deceive permet de recueillir des renseignements sur l’attaquant sans révéler le fait de la détection.

// Exemple : vérification RASP de l’appel Runtime.exec()
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // Vérification de l’appelant
        String caller = stack[1].getClassName();

        // Si l’appel ne vient pas de notre paquet — suspect
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // Vérification de la commande contre la liste noire
        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 : processus vide
            }
        }

        return null; // autoriser l’exécution
    }
}

RASP vs WAF et autres outils de sécurité

RASP est souvent comparé au pare-feu d’application Web (WAF), mais la différence fondamentale réside dans le positionnement. Le WAF se situe en périphérie du réseau et analyse uniquement les requêtes HTTP. RASP fonctionne à l’intérieur de l’application et voit la logique de traitement.

Contrairement à l’obfuscation (ProGuard, DexGuard), qui rend le code illisible, RASP détecte activement les attaques pendant l’exploitation. L’obfuscation est une protection passive : si l’attaquant consacre suffisamment de temps au reverse engineering, le code sera lu. RASP est actif : il voit que l’attaquant tente de déboguer l’application et réagit avant qu’une seule ligne de code ne soit lue. La combinaison d’obfuscation + RASP fournit une protection multicouche, où l’obfuscation ralentit l’analyse et RASP interrompt l’attaque au stade de l’instrumentation.

RASP dans les applications mobiles

Les solutions RASP mobiles sont adaptées aux spécificités d’Android et d’iOS. Contrairement aux applications Java côté serveur, les agents RASP mobiles fonctionnent dans des conditions de mémoire et de batterie limitées, nécessitant une instrumentation légère.

RASP sur Android

Sur Android, l’agent RASP est intégré via un plugin Gradle qui modifie le bytecode DEX lors de la compilation. L’agent intercepte plus de 50 appels système, notamment : Runtime.exec() pour détecter l’exécution de su ou de Frida, Class.forName() pour identifier le chargement de classes suspectes, System.loadLibrary() pour contrôler le chargement de bibliothèques natives à partir de chemins non standard. De plus, il vérifie dans /proc/self/maps la présence des bibliothèques frida-agent, frida-helper, libinject et substrate.

RASP sur iOS

Sur iOS, RASP est implémenté par post-traitement du binaire Mach-O. iOS est plus complexe en raison des exigences strictes d’Apple concernant la modification des binaires. L’agent intercepte les appels aux fonctions fork(), dlopen(), ptrace() et vérifie la présence de CydiaSubstrate.dylib parmi les bibliothèques chargées. RASP pour iOS ne peut pas modifier le code dans les builds App Store — uniquement pour la distribution Enterprise. Pour l’App Store, l’instrumentation au moment de la compilation via Swift Macro ou le method swizzling Objective-C est recommandée.

Détection des outils d’analyse

Le RASP mobile détecte : Frida (via la vérification de /proc/self/maps et /data/local/tmp/frida*), Xposed Framework (via la vérification de de.robv.android.xposed.XposedBridge dans ClassLoader), le débogueur JDWP (via Debug.isDebuggerConnected()), les émulateurs (via la vérification de Build.FINGERPRINT, Build.HARDWARE, Build.MODEL) et le flag debuggable dans AndroidManifest. Selon le NowSecure Mobile Threat Report (2025), un agent RASP détecte 89–97 % des sessions instrumentées de Frida.

Implémentation pratique d’un agent RASP

L’intégration de RASP dans une application mobile nécessite la configuration de l’instrumentation, la définition des politiques et l’intégration avec un système SIEM pour la collecte des journaux d’incidents.

Choix de l’implémentation : compilation vs exécution

L’instrumentation au moment de la compilation — modification du bytecode lors de la compilation, n’affecte pas les performances à l’exécution. L’instrumentation au moment de l’exécution (via Java Agent sur le serveur ou Frida sur le client) est plus flexible mais ajoute 5–10 % de surcharge. Pour les applications mobiles, l’approche au moment de la compilation est recommandée car elle ne nécessite pas de connexion réseau constante et ne consomme pas la batterie pour l’analyse.

Intégration avec les bibliothèques existantes

L’agent RASP doit fonctionner correctement avec les SDK populaires. Firebase Crashlytics, Google Analytics et Appsee ne doivent pas être bloqués. La configuration de la liste blanche pour les bibliothèques connues est obligatoire. Dans la configuration de l’agent, des exceptions sont spécifiées : si un appel provient de la classe com.google.firebase — la vérification est ignorée. La liste blanche est mise à jour avec chaque version du SDK.

Exemple de traitement d’incident

Lorsque Frida est détecté via l’agent RASP, ce qui suit se produit : collecte du contexte (trace de pile, version de l’OS, heure), envoi des données au serveur de journalisation sous forme chiffrée, exécution de la politique (crash, journalisation seule ou deceive), incrémentation d’un compteur pour identifier une attaque de masse. Les données de différents appareils sont agrégées sur le serveur pour identifier les modèles d’attaque.

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

Limitations et faux positifs

RASP n’est pas une solution miracle. La technologie a des limites qui doivent être prises en compte lors de la conception de la protection.

Performances

Chaque appel intercepté ajoute une vérification de contexte. Avec une configuration agressive (interception de tous les appels d’E/S et exec), les performances peuvent chuter de 5 à 15 %. Le temps de démarrage est critique pour les applications mobiles : l’initialisation de RASP ajoute 200 à 500 ms au lancement. Une instrumentation ciblée est recommandée — uniquement les fonctions critiques, pas toutes les fonctions possibles. Le profilage avec l’agent RASP est obligatoire lors des tests.

Faux positifs

RASP peut bloquer un comportement légitime : Firebase Crashlytics envoyant une pile d’erreurs via un appel réseau pourrait être confondu avec une exfiltration de données ; l’API Google Play Integrity vérifiant l’intégrité de l’appareil pourrait être identifiée comme un appel suspect. Pour réduire les faux positifs, une période de mode d’apprentissage (learning mode) de 7 à 14 jours est nécessaire, pendant laquelle RASP ne fait que journaliser mais ne bloque pas.

Contournement de RASP

Si un attaquant obtient un accès au niveau du noyau (via un exploit du noyau), RASP ne peut pas faire confiance même à ses propres vérifications — l’agent opère dans l’espace utilisateur et ne voit que ce que le noyau lui permet de voir. Pour prévenir le contournement au niveau du noyau, la vérification de Secure Boot Chain est utilisée en combinaison avec l’attestation du serveur. De plus, l’agent RASP lui-même doit être obscurci et protégé contre le débogage — sinon l’attaquant supprimera ou désactivera RASP avant de lancer l’attaque.