Un RASP qui ne bloque pas vos vrais clients

La protection à l’exécution, ou RASP, est désormais attendue dans les apps bancaires et les autres apps qui gèrent de l’argent. Banques partenaires, auditeurs et équipes antifraude demandent une détection du root, une détection du hooking et des contrôles anti-altération.

Le plus difficile n’est pas de détecter les menaces. C’est de les détecter sans bloquer de vrais clients. Un contrôle qui exclut un utilisateur légitime sur un appareil inhabituel, c’est un ticket au support, un mauvais avis et parfois un client perdu.

Dans cet article, nous expliquons comment nous avons conçu et vérifié la protection à l’exécution de l’app Android d’une banque de détail, et les choix de conception qui ont limité les faux positifs.

---

Ce que l’app devait détecter

• Les frameworks de hooking comme Frida, capables de modifier le comportement de l’app à l’exécution.

• Les appareils rootés, sur lesquels les protections du système d’exploitation ne tiennent plus.

• Les émulateurs, souvent utilisés pour des abus automatisés à grande échelle.

• Les apps repackagées, modifiées et redistribuées en dehors du store officiel.

• Les abus d’overlay et d’accessibilité, une technique courante des malwares bancaires.

📌 À retenir :

Chaque détecteur peut échouer de deux façons : en laissant passer une attaque, ou en signalant un utilisateur honnête. La plupart des discussions sur le RASP n’évoquent que la première.

---

Les choix de conception qui ont limité les faux positifs

1. Des valeurs exactes, pas des heuristiques approximatives

De nombreux contrôles anti-émulateur recherchent des mots suspects dans les propriétés de l’appareil. Ils attrapent aussi du vrai matériel aux noms inhabituels. Nous sommes passés à une détection d’émulateur par valeurs exactes, couverte par 35 tests, et avons vérifié l’absence de faux positifs sur les Chromebooks, qui exécutent des apps Android et déclenchent souvent les contrôles naïfs.

2. Des classifieurs testés sur de vraies apps

Pour la détection des autoclickers, nous avons conçu un classifieur et l’avons testé sur de vraies apps, pas seulement sur des échantillons de laboratoire. C’est sur des logiciels réels qu’un classifieur gagne la confiance ou commence à bloquer des utilisateurs honnêtes.

3. Des contrôles d’identité indépendants de l’appareil

L’anti-repackaging s’appuie sur une vérification du certificat de signature et une vérification de l’installateur. Toutes deux portent sur l’app elle-même : elles se comportent donc de la même manière sur tous les téléphones.

4. Un kill-switch pour chaque détecteur

La détection à l’exécution est placée derrière un kill-switch à distance. Si un nouveau modèle de téléphone se met à déclencher un contrôle, l’équipe n’a pas à attendre une publication sur le store pour cesser de bloquer des utilisateurs.

---

Comment nous avons vérifié la détection

La matrice de vérification a exécuté chaque scénario sur des builds de test :

Scénario	Résultat attendu
Frida attaché à l’app	Écran de blocage en moins de 5 secondes
App lancée sur un émulateur	Bloquée
App lancée sur un vrai téléphone	Fonctionne normalement

Tester les lignes « doit passer » est aussi important que tester les lignes « doit bloquer ». C’est là que les faux positifs sont repérés avant que les clients ne les découvrent.

---

Ce que le RASP ne fait pas

• Il ne rend pas une app inviolable. Un attaquant déterminé peut contourner les contrôles côté client s’il y consacre assez de temps.

• Il ne remplace pas les contrôles côté serveur comme la validation des sessions et le scoring antifraude.

• Il ne couvre pas les exigences propres à un secteur, comme la géolocalisation certifiée pour les jeux d’argent.

Ce qu’il fait bien : augmenter le coût des attaques courantes, bloquer les outils prêts à l’emploi et les abus automatisés, et fournir au backend des signaux exploitables.

Comment Mobian vous aide

Chez Mobian, ces contrôles à l’exécution faisaient partie d’une remédiation de sécurité pour une banque de détail, partie d’un score MobSF de 48/100 et qui a abouti à 124 correctifs suivis. Nous concevons la détection pour les utilisateurs que vous avez, pas seulement pour les attaquants que vous redoutez — avec des tests pour les deux, et un moyen de couper un contrôle s’il se comporte mal.

Conclusion

Un bon RASP se mesure sur deux plans : la rapidité avec laquelle il arrête un outil de hooking, et la rareté avec laquelle il dérange un vrai client. Des contrôles par valeurs exactes, des classifieurs testés sur des apps légitimes, des contrôles d’identité indépendants de l’appareil et un kill-switch à distance permettent de bloquer Frida en quelques secondes, tandis qu’un client sur Chromebook ne remarque absolument rien.

Questions fréquentes

Qu’est-ce que le RASP dans une app mobile ?

Le Runtime Application Self-Protection (RASP) est un ensemble de contrôles qu’une app exécute sur elle-même pendant son utilisation : détection du root, des outils de hooking comme Frida, des émulateurs, des débogueurs et des versions repackagées de l’app. Lorsqu’un contrôle se déclenche, l’app peut bloquer l’accès, limiter certaines fonctionnalités ou envoyer un signalement au serveur.

Pourquoi les contrôles RASP provoquent-ils des faux positifs ?

Beaucoup de détections reposent sur des heuristiques approximatives, comme rechercher dans les propriétés de l’appareil des mots associés aux émulateurs. De vrais appareils, y compris les Chromebooks qui exécutent des apps Android, peuvent correspondre à ces motifs. Un faux positif empêche un client payant d’accéder à son propre compte.

Qu’est-ce qu’un kill-switch RASP ?

Un paramètre à distance qui permet à l’équipe de désactiver ou d’assouplir un détecteur précis sans publier de nouvelle version de l’app. Si un contrôle commence à bloquer de vrais utilisateurs sur un appareil donné, l’équipe peut le couper en quelques minutes, le temps de préparer un correctif.

Le RASP peut-il arrêter un attaquant déterminé ?

Non. Un attaquant compétent qui dispose de suffisamment de temps peut contourner les contrôles côté client. Le RASP augmente le coût des attaques, bloque les outils courants et les abus automatisés, et fournit au serveur des signaux exploitables. Il complète une conception sécurisée et les contrôles côté serveur ; il ne les remplace pas.

Le RASP est-il utile en dehors de la banque ?

Oui. Les fermes d’émulateurs, les autoclickers et les apps repackagées alimentent l’abus de bonus dans le jeu et la fraude dans les apps crypto. Les mêmes détecteurs s’appliquent, même si chaque secteur a aussi des exigences spécifiques, comme la géolocalisation certifiée, que le RASP ne couvre pas.