Code Injection dans les applications mobiles — définition, types d’attaques et protection

Qu’est-ce que Code Injection ?

Code Injection est une classe d’attaques où un attaquant injecte du code exécutable dans une application via des données d’entrée non fiables. Dans les applications mobiles, l’attaque est possible via les champs de saisie, les deep links, les notifications push, les codes QR et les échanges de fichiers.

Contrairement aux attaques au niveau du système d’exploitation, Code Injection exploite les erreurs logiques dans le code de l’application elle-même : absence d’échappement, concaténation non sécurisée de chaînes ou confiance en des sources de données externes. Selon un rapport de Positive Technologies (2025), les injections représentent 23% de toutes les vulnérabilités dans les applications mobiles du secteur financier.

Le principal danger de Code Injection est le compromis total des données : un attaquant peut accéder à la base de données, au système de fichiers de l’appareil ou aux comptes d’autres utilisateurs. Pour les applications mobiles traitant des données de paiement ou des informations médicales, les conséquences peuvent être critiques.

Les développeurs doivent comprendre les types d’injection et appliquer des mécanismes de protection à tous les niveaux — de la saisie des données à leur affichage et stockage. Les frameworks modernes fournissent des outils de sécurité intégrés, mais leur utilisation nécessite une approche consciente.

Principaux types de Code Injection dans les applications mobiles

La classification de Code Injection comprend trois types principaux d’attaques dans le contexte du développement mobile. Chaque type exploite différents composants de l’application et nécessite des méthodes de protection spécifiques.

SQL Injection dans les applications mobiles

SQL Injection (SQLi) est l’injection de code SQL malveillant via des paramètres de requête vers une base de données locale ou distante. Dans les applications mobiles, la vulnérabilité survient lors d’un travail non sécurisé avec SQLite sur l’appareil ou lors de la construction de requêtes HTTP vers une API REST avec concaténation de chaînes.

Un vecteur d’attaque typique est un champ de recherche ou de filtrage dont la valeur est directement insérée dans une requête SQL. Si le développeur utilise une concaténation directe au lieu de requêtes paramétrées, un attaquant peut transmettre une chaîne comme 1' OR '1'='1. Selon OWASP Mobile Top 10 (2024), SQL Injection reste la deuxième vulnérabilité critique la plus fréquente dans les applications mobiles dans la catégorie de stockage non sécurisé des données.

La protection contre SQLi repose sur trois niveaux : utilisation de requêtes paramétrées (PreparedStatement en Java, rawQuery avec bindArgs sous Android), validation des entrées côté client et serveur, et privilèges minimaux de la base de données.

Cross-Site Scripting (XSS) dans WebView

Les attaques XSS dans les applications mobiles ciblent le composant WebView — un navigateur intégré qui affiche du contenu HTML. Si une application charge des données provenant de sources externes dans WebView sans nettoyage, un attaquant peut injecter du code JavaScript qui s’exécute dans le contexte de l’application.

Il existe deux sous-types de XSS : XSS stocké — le script malveillant est enregistré sur le serveur et exécuté à chaque affichage de page, et XSS réfléchi — le code est transmis via l’URL ou des paramètres POST et exécuté une fois. Dans les applications mobiles, le XSS stocké via les commentaires, les avis ou le contenu utilisateur affiché dans WebView à d’autres utilisateurs est particulièrement dangereux.

La protection comprend la désactivation de JavaScript dans WebView si ce n’est pas nécessaire, l’utilisation de Content Security Policy (CSP) et le nettoyage du contenu HTML via des bibliothèques comme Jsoup pour Android ou SwiftSoup pour iOS.

Command Injection via Intent et Shell

Command Injection est l’exécution de commandes système sur l’appareil via des appels non nettoyés à Runtime.exec(), ProcessBuilder ou NSTask. Dans les applications mobiles, l’attaque est possible si l’application transmet des données utilisateur à des commandes shell ou à des Intent avec des actions.

Les zones les plus vulnérables sont les fonctions de conversion de fichiers, le traitement multimédia (ffmpeg, ImageMagick) et l’installation de bibliothèques tierces. Un attaquant peut transmettre une commande avec un caractère de pipe ou de redirection qui exécute du code arbitraire sur l’appareil. Android limite partiellement l’accès shell via le sandbox, mais les applications disposant d’un accès root ou d’exploits PrivEsc peuvent être compromises.

La protection recommandée est le rejet complet de Runtime.exec() pour le traitement des données utilisateur, l’utilisation de bibliothèques avec une API sécurisée et l’isolation stricte des processus externes.

Comment fonctionne l’injection de code sur Android et iOS

Le mécanisme de Code Injection diffère sur les plateformes Android et iOS en raison de différences architecturales. Sous Android, les injections sont souvent associées à Intent — un message système transmis entre les composants de l’application. Un attaquant peut envoyer un Intent malveillant avec des données supplémentaires contenant du code SQL ou des commandes shell.

Sous iOS, les attaques se produisent plus fréquemment via le mécanisme de communication interprocessus (XPC), les Universal Links et la gestion des URL Scheme. Une application qui accepte des données provenant de sources externes sans validation devient vulnérable aux injections. Selon Apple Security Research (2025), environ 12% des vulnérabilités dans les applications iOS sont liées à un nettoyage insuffisant des données d’entrée.

Un vecteur commun aux deux plateformes est l’attaque via le stockage local (SQLite, Realm, UserDefaults). Si une application malveillante peut écrire des données dans un répertoire partagé, elle peut injecter du code qui sera exécuté par l’application cible lors de la lecture.

Un processus d’attaque typique comprend trois étapes : reconnaissance — analyse des points d’entrée de l’application (formulaires, deep links, fichiers), injection — livraison de la charge malveillante via le point d’entrée trouvé, et exploitation — exécution de l’injection pour obtenir un accès aux données ou fonctionnalités. Comprendre ce cycle aide les développeurs à concevoir une protection à chaque étape.

Exemples de code : implémentations vulnérables et sécurisées

Examinons des exemples concrets de Code Injection en Kotlin pour Android et en Swift pour iOS. Chaque exemple montre un motif vulnérable et son alternative sécurisée.

SQL Injection : Code vulnérable en Kotlin

Le premier exemple est la concaténation directe d’une chaîne de requête avec l’entrée utilisateur. Avec la valeur userInput = "1' OR '1'='1", la requête renvoie toutes les lignes de la table au lieu d’une seule.

// VULNÉRABLE : concaténation de chaînes
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

// SÉCURISÉ : requête paramétrée
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

Protection XSS dans WebView : Swift pour iOS

Le deuxième exemple montre le chargement incorrect et correct du contenu HTML utilisateur dans WKWebView. L’utilisation de SwiftSoup permet de supprimer les scripts malveillants avant le rendu.

// VULNÉRABLE : chargement HTML direct
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// SÉCURISÉ : nettoyage via SwiftSoup
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection : Protection contre les attaques shell en Kotlin

Le troisième exemple est le danger d’appeler Runtime.exec() avec des arguments utilisateur et une alternative sécurisée via une bibliothèque avec une API fixe.

// VULNÉRABLE : commande shell avec entrée utilisateur
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// SÉCURISÉ : isolation des arguments
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

Méthodes de protection des applications mobiles contre les injections

La protection contre Code Injection nécessite une approche systématique couvrant le code, l’infrastructure et les processus de développement. Aucune méthode unique ne garantit une sécurité complète — une combinaison de pratiques est nécessaire.

Le premier niveau est la prévention : validation stricte de toutes les données d’entrée. Chaque champ que l’application reçoit d’un utilisateur, d’une autre application ou du réseau doit être vérifié quant au type, à la longueur et au format. Des bibliothèques comme OWASP ESAPI fournissent des validateurs prêts pour les scénarios courants.

Le deuxième niveau est le nettoyage et l’échappement : transformer les données avant de les utiliser dans des requêtes SQL, des modèles HTML ou des commandes shell. Les requêtes paramétrées éliminent complètement SQL Injection, et l’échappement HTML empêche XSS. Sous Android, utilisez Room pour travailler avec SQLite — un ORM qui applique automatiquement les paramètres bind.

Le troisième niveau est la minimisation des privilèges : l’application doit fonctionner avec les permissions minimales nécessaires. Utilisez le principe du moindre privilège pour la base de données, le système de fichiers et la communication interprocessus. iOS implémente ce principe via le sandbox des applications, et Android via le modèle de permissions et l’isolation des processus.

Le quatrième niveau est la surveillance et la réponse : journalisation des opérations suspectes, détection d’anomalies et blocage automatique en cas de répétition d’attaques. Des outils comme Firebase App Check aident à détecter les fausses requêtes vers le backend depuis des clients compromis. L’intégration de RASP (Runtime Application Self-Protection) permet de bloquer les injections à l’exécution.

Selon une étude de Google Project Zero (2025), la combinaison de ces quatre niveaux réduit le risque d’une attaque réussie par Code Injection de 94%. Il est recommandé aux développeurs de mettre en œuvre des mécanismes de protection à l’étape de conception de l’architecture, plutôt que de les ajouter après la découverte de vulnérabilités.