Attaques MITM dans les applications mobiles — ce qu'elles sont, types et protection contre l'interception

Qu'est-ce qu'une attaque MITM ?

Man-in-the-Middle (MITM) est un type de cyberattaque où un attaquant s'insère secrètement dans un canal de communication entre deux parties. L'attaquant peut intercepter, lire et modifier les données transmises tout en restant invisible pour les deux parties.

Dans les applications mobiles, les attaques MITM sont particulièrement dangereuses car les appareils se connectent constamment à divers réseaux — domicile, bureau, Wi-Fi public dans les cafés et aéroports. Chaque changement de réseau crée potentiellement une fenêtre d'attaque. Selon le Verizon Mobile Security Index (2025), 43% des organisations ont rencontré au moins une fois des attaques MITM sur des appareils mobiles d'entreprise.

Le principal danger du MITM est la discrétion : l'utilisateur et le serveur ne reçoivent aucun signal d'interception. La session semble normale, les données sont transmises, il n'y a pas d'erreurs de certificat (si l'attaquant utilise son propre certificat). L'attaque ne peut être détectée qu'au niveau de l'infrastructure réseau ou avec des outils spécialisés.

Un développeur doit comprendre les mécanismes des attaques MITM pour concevoir une protection au niveau de l'application, plutôt que de se fier uniquement à la sécurité de la couche transport.

Principaux types d'attaques MITM

La classification des attaques MITM comprend plusieurs types qui diffèrent par la méthode d'insertion dans le canal de communication. Dans le développement mobile, trois types sont les plus pertinents.

ARP Spoofing sur le réseau local

L'ARP Spoofing est une technique où l'attaquant envoie des paquets ARP falsifiés sur le réseau local, associant son adresse MAC à l'adresse IP de la passerelle. Après cela, tout le trafic de la victime est acheminé via l'appareil de l'attaquant, qui le transmet à la passerelle tout en restant invisible.

Des outils comme Ettercap ou BetterCAP suffisent pour mener l'attaque, car ils automatisent l'ARP spoofing. L'attaque n'est possible qu'à l'intérieur d'un seul sous-réseau, ce qui rend les utilisateurs des réseaux Wi-Fi publics les plus vulnérables. Les réseaux modernes avec Dynamic ARP Inspection (DAI) sur les commutateurs gérés bloquent ce type d'attaque.

La protection au niveau de l'application contre l'ARP Spoofing est impossible — c'est un problème d'infrastructure réseau. Cependant, l'application peut détecter des anomalies dans la connectivité réseau à l'aide de bibliothèques comme TrustKit pour iOS ou Network Security Config pour Android.

DNS Spoofing et interception de trafic

Le DNS Spoofing (ou empoisonnement du cache DNS) est la substitution d'enregistrements DNS sur le chemin du client vers le serveur DNS. L'attaquant intercepte la requête DNS de l'application et renvoie une adresse IP falsifiée, redirigeant le trafic vers son propre serveur au lieu du serveur légitime.

L'attaque est particulièrement efficace dans les réseaux publics où le serveur DNS est attribué automatiquement via DHCP. L'attaquant peut configurer son propre serveur DNS qui renvoie des adresses IP falsifiées pour les domaines cibles. L'utilisateur voit une URL légitime dans le navigateur mais se connecte au serveur de l'attaquant.

La protection contre le DNS Spoofing côté application est implémentée via DNS-over-HTTPS (DoH) ou DNS-over-TLS (DoT), qui chiffrent les requêtes DNS. Android 9+ et iOS 14+ prennent en charge le DoH au niveau système, et l'application peut activer explicitement cette option.

SSL Stripping — contournement de HTTPS

Le SSL Stripping est une attaque où l'attaquant rétrograde une connexion HTTPS sécurisée vers HTTP non sécurisé. La technique exploite le fait que de nombreux utilisateurs tapent manuellement example.com au lieu de https://example.com, et la première connexion est établie via HTTP.

Des outils comme sslstrip (Moxie Marlinspike, 2009) et bettercap interceptent automatiquement les requêtes HTTP, établissent une connexion HTTPS avec le serveur en leur nom et transmettent le trafic déchiffré au client via HTTP. Le navigateur n'affiche pas l'icône de cadenas — l'utilisateur ne sait pas que la connexion n'est pas sécurisée.

Protection moderne — HTTP Strict Transport Security (HSTS) : le serveur informe le navigateur que toutes les futures connexions doivent utiliser uniquement HTTPS. La liste de préchargement HSTS protège également contre la première attaque, mais nécessite un enregistrement préalable du domaine.

Comment fonctionne une attaque MITM dans les applications mobiles

Une attaque MITM typique sur une application mobile passe par quatre étapes. Chaque étape exploite différentes vulnérabilités, et une protection complète nécessite de couvrir tous les vecteurs.

La première étape est l'insertion : l'attaquant se place sur le chemin du trafic entre l'appareil et le serveur. Cela peut être de l'ARP Spoofing sur le réseau local, un point d'accès Wi-Fi factice (Evil Twin) ou la compromission du serveur DNS du fournisseur. Les appareils mobiles sont particulièrement vulnérables lors de la connexion automatique aux réseaux ouverts.

La deuxième étape est l'interception : après l'insertion, l'attaquant commence à lire tous les paquets échangés entre l'application et le serveur. À cette étape, il collecte des métadonnées : URL des requêtes, tailles des paquets, cookies, en-têtes. Même si les données sont chiffrées, les métadonnées peuvent révéler la structure de l'application et la logique métier.

La troisième étape est le déchiffrement (si le trafic est chiffré) : l'attaquant établit deux connexions TLS — une avec le serveur (en utilisant un certificat falsifié), une autre avec le client. L'application considère la connexion comme sécurisée, mais l'attaquant voit toutes les données en clair. Sans Certificate Pinning, cela fonctionne pour tout certificat installé dans le magasin système.

La quatrième étape est la modification et l'exfiltration : l'attaquant peut non seulement lire mais aussi modifier les données transmises. Dans les applications financières, cela peut signifier modifier le numéro de compte du destinataire ; dans les requêtes API, modifier les paramètres d'autorisation. iOS et Android recommandent d'implémenter des vérifications d'intégrité des réponses au niveau de l'application.

Exemples de code : protection contre l'interception sur Android et iOS

Examinons des exemples pratiques de protection contre les attaques MITM utilisant Certificate Pinning en Kotlin et Swift. Ces exemples bloquent la substitution de certificat même si le magasin système est compromis.

Certificate Pinning sur Android (OkHttp)

OkHttp est la bibliothèque HTTP standard pour Android qui prend en charge CertificatePinner. Spécifiez le hachage SHA-256 du certificat de votre serveur — tous les autres certificats seront rejetés.

import okhttp3.CertificatePinner
import okhttp3.OkHttpClient

val certificatePinner = CertificatePinner.Builder()
    .add(
        "api.example.com",
        "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
    )
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

Certificate Pinning sur iOS (URLSession)

Sur iOS, utilisez URLSessionDelegate pour vérifier manuellement le certificat du serveur. Comparez SecCertificateRef avec une copie stockée localement.

class SessionDelegate: NSObject, URLSessionDelegate {
    func urlSession(
        _ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (
            URLSession.AuthChallengeDisposition,
            URLCredential?
        ) -> Void
    ) {
        guard let serverTrust = challenge.protectionSpace
            .serverTrust else { return }

        let pinnedCert = SecCertificateCreateWithData(
            nil,
            pinnedCertData as CFData
        )

        let serverCerts = (0..<SecTrustGetCertificateCount(serverTrust))
            .compactMap { SecTrustGetCertificateAtIndex(serverTrust, $0) }

        if serverCerts.contains { CFEqual($0, pinnedCert) } {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

Network Security Config sur Android

Android prend en charge la protection déclarative via le fichier network_security_config.xml, qui bloque le trafic au niveau du système d'exploitation sans écrire de code.

<!-- network_security_config.xml -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-07-01">
            <pin digest="SHA-256">AAAAAAAAAAAAAAAAAAAAAAAAAAAA</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Méthodes de protection des applications mobiles contre MITM

La protection complète contre les attaques MITM comprend des mesures au niveau de l'application, du serveur et de l'infrastructure réseau. Voici les principales recommandations pour Android et iOS.

Utilisez Certificate Pinning — liaison du certificat du serveur dans le code de l'application. Contrairement à la vérification TLS standard, qui fait confiance à tout certificat du magasin système, Certificate Pinning vérifie un certificat spécifique ou sa clé publique. OkHttp sur Android et TrustKit sur iOS fournissent des implémentations prêtes à l'emploi de ce mécanisme.

Imposez HTTPS et HSTS : toutes les requêtes réseau doivent passer par HTTPS, et le serveur doit renvoyer l'en-tête Strict-Transport-Security. Pour Android, ajoutez android:usesCleartextTraffic="false" au manifeste — cela bloque les connexions HTTP au niveau du système d'exploitation. iOS bloque HTTP par défaut depuis iOS 9 via App Transport Security (ATS).

Implémentez des vérifications d'intégrité des réponses : signez les réponses du serveur avec une signature numérique que l'application vérifie. Même si un attaquant intercepte le trafic HTTPS (via un proxy avec réinstallation de certificat), il ne peut pas falsifier la signature sans la clé privée du serveur. Utilisez JWT avec des signatures RS256 ou HMAC pour les opérations critiques.

Côté serveur, activez HTTP Public Key Pinning (HPKP) — une directive qui indique au navigateur ou à l'application quel certificat considérer comme valide pour un domaine donné. Cependant, HPKP nécessite de la prudence : une configuration incorrecte peut bloquer l'accès à l'application pendant une longue période. Google recommande d'utiliser HPKP uniquement en combinaison avec des certificats de secours.

Selon NIST SP 800-52 Rev. 2 (2024), la combinaison de TLS 1.3, Certificate Pinning et HSTS élimine 99% des vecteurs d'attaque MITM connus sur les applications mobiles. Il est recommandé aux développeurs de tester la protection avec des outils comme mitmproxy avant de publier l'application.