Sécurité dans le développement mobile : définition, menaces et comment se protéger

Menaces Principales : OWASP Mobile Top 10

Qu'est-ce que OWASP Mobile Top 10 ?

OWASP (Open Web Application Security Project) est une organisation à but non lucratif qui publie un classement des vulnérabilités les plus dangereuses de la sécurité mobile. OWASP Mobile Top 10 est une liste qui aide les développeurs à comprendre sur quoi se concentrer en premier. Dans la version 2024, les problèmes liés au stockage non sécurisé, à l'authentification faible et aux communications réseau non sécurisées sont en tête du classement.

M1 : Stockage Non Sécurisé des Données — le problème le plus courant : mots de passe, jetons et données personnelles restent dans SharedPreferences, NSUserDefaults ou des fichiers locaux sans chiffrement. M2 : Authentification Faible — absence de vérification côté serveur, mots de passe faibles. M3 : Communication Réseau Non Sécurisée — absence de HTTPS ou vérification incorrecte du certificat SSL. M4 et M5 sont liés à la cryptographie et à une mauvaise utilisation de l'API.

M6 : Autorisation Non Sécurisée — un utilisateur peut accéder aux données d'un autre utilisateur en substituant un ID dans une requête. M7 : Injection de Code (SQL Injection, XSS). M8 : Manipulation de l'Application — reconditionnement, substitution de code. M9 et M10 — fuite de données via des bibliothèques tierces et rétro-ingénierie. Pour chacune de ces menaces, il existe des contre-mesures éprouvées, et chez IT Sectr nous les appliquons dans tous les projets depuis 2017.

Attaques Man-in-the-Middle (MITM)

L'attaque MITM se produit lorsqu'un attaquant intercepte le trafic entre l'application et le serveur. Cela est possible par usurpation DNS, ARP spoofing ou connexion à un réseau Wi-Fi non sécurisé. Des certificats SSL/TLS et le Certificate Pinning sont utilisés pour la protection.

Certificate Pinning est un mécanisme par lequel l'application vérifie que le certificat du serveur correspond à un certificat pré-enregistré dans le code de l'application. Même si un attaquant substitue le certificat via un proxy (par exemple, Burp Suite), l'application rejettera la connexion. Le Pinning existe en deux types : Public Key Pinning et Certificate Hash Pinning.

Chiffrement et Hachage : AES, RSA, SSL/TLS

Chiffrement Symétrique : AES

AES (Advanced Encryption Standard) est un algorithme de chiffrement symétrique, le fondement de la sécurité des données sur l'appareil. AES utilise la même clé pour chiffrer et déchiffrer les données. AES prend en charge des clés de 128, 192 ou 256 bits. Dans le développement mobile, AES-256 est utilisé pour chiffrer les données sur l'appareil : fichiers, cache, enregistrements dans la base de données locale.

Modes AES : GCM (recommandé) — assure l'authentification des données, CBC — mode de base avec chaînage de blocs, ECB — non sécurisé, ne l'utilisez pas. Pour iOS, AES est disponible via CommonCrypto (CCOptions), pour Android — via Cipher dans Java Cryptography Architecture (JCA). Important : la clé de chiffrement ne doit jamais être stockée dans le code de l'application — utilisez Keychain/Keystore.

Chiffrement Asymétrique : RSA — utilise une paire de clés (publique et privée). RSA est utilisé pour chiffrer de petites quantités de données — généralement pour échanger une clé symétrique entre le client et le serveur. La longueur minimale de clé RSA est de 2048 bits (4096 recommandé). Sur iOS, RSA est disponible via Security Framework (SecKeyCreateRandomKey), sur Android — via KeyPairGenerator dans Android Keystore.

Hachage et SSL/TLS

Hachage (SHA-256, SHA-3) est une transformation irréversible de données en une chaîne de longueur fixe. Les hachages sont utilisés pour vérifier l'intégrité des données et stocker les mots de passe. Pour les mots de passe, utilisez impérativement bcrypt, scrypt ou Argon2 — le simple SHA-256 est vulnérable aux attaques par tables rainbow. SSL/TLS est un protocole de chiffrement du trafic réseau entre le client et le serveur. Le standard moderne est TLS 1.3, qui assure Perfect Forward Secrecy (PFS).

TLS 1.3 est plus rapide que ses prédécesseurs : la poignée de main (handshake) prend un aller-retour au lieu de deux. Sur Android, la version minimale de TLS est configurée via SSLSocket, sur iOS — via ATS (App Transport Security), qui par défaut exige TLS 1.2 ou supérieur. ATS ne peut être désactivé que pour des domaines spécifiques avec justification.

Stockage Sécurisé : Keychain et Keystore

iOS : Keychain

Keychain (Trousseau) est un stockage sécurisé dans iOS / macOS pour les mots de passe, clés de chiffrement, certificats et jetons. Les données dans Keychain sont chiffrées avec une clé matérielle unique pour chaque appareil. L'accès à Keychain est contrôlé via Security Framework (SecItemAdd, SecItemCopyMatching). Keychain se verrouille automatiquement lorsque l'appareil se verrouille et est chiffré via Secure Enclave.

Android : Keystore

Android Keystore est un stockage système pour les clés cryptographiques, isolé de l'application. À partir d'Android 6.0 (API 23), Keystore utilise le support matériel (TEE — Trusted Execution Environment) sur les appareils avec une puce de sécurité. Les clés dans Keystore ne quittent jamais la zone sécurisée — l'application ne reçoit qu'un handle pour les opérations de chiffrement et de signature.

SharedPreferences et NSUserDefaults ne sont pas conçus pour stocker des données sensibles — ils stockent les informations en clair. Pour la protection des données, utilisez EncryptedSharedPreferences (Android) ou chiffrez les données avant de les sauvegarder dans UserDefaults (iOS). Chez IT Sectr, nous utilisons toujours Keychain et Keystore pour les jetons d'accès et les mots de passe.

Authentification : OAuth 2.0, JWT et Biométrie

OAuth 2.0 et OpenID Connect

OAuth 2.0 est un protocole d'autorisation déléguée qui permet un accès sécurisé aux ressources de l'utilisateur sans transmission de mot de passe. Dans les applications mobiles, le flux Authorization Code avec PKCE (Proof Key for Code Exchange) est le plus couramment utilisé. PKCE empêche l'interception du code d'autorisation — une exigence obligatoire pour les applications mobiles.

OpenID Connect (OIDC) est une extension au-dessus d'OAuth 2.0 pour l'authentification de l'utilisateur. OIDC ajoute un ID Token au format JWT qui contient les informations de l'utilisateur (nom, email, id). Le flux OAuth 2.0 + OIDC comprend : redirection de l'utilisateur vers la page de connexion, obtention d'un code d'autorisation, échange du code contre des jetons (access + refresh + id), utilisation du jeton d'accès pour les requêtes API.

JWT : Jetons d'Accès, de Rafraîchissement et de Session

JWT (JSON Web Token) est un format de jeton compact et sécurisé pour les URL qui contient des revendications au format JSON. JWT se compose de trois parties : en-tête (type et algorithme de signature), payload (données) et signature. Le jeton d'accès est un jeton à courte durée de vie (15 à 60 minutes) pour l'accès à l'API. Le jeton de rafraîchissement est un jeton à longue durée de vie (jours/semaines) pour obtenir un nouveau jeton d'accès sans reconnexion.

Jeton de Session est une approche traditionnelle où le serveur stocke la session dans une base de données ou Redis, et le client reçoit un identifiant aléatoire. Dans le développement mobile, JWT est préféré : il ne nécessite pas de stockage de session côté serveur, contient toutes les informations en lui-même et est facile à vérifier. Cependant, JWT ne peut pas être révoqué instantanément — c'est un compromis qui est résolu par une courte durée de vie du jeton d'accès et l'utilisation de jetons de rafraîchissement.

Authentification Biométrique

Face ID et Touch ID sur iOS, Authentification par Empreinte sur Android — des méthodes d'authentification biométrique qui utilisent les caractéristiques physiques uniques de l'utilisateur. Sur iOS, la biométrie fonctionne via LocalAuthentication (LAContext), sur Android — via BiometricPrompt (Android 9+) ou FingerprintManager (obsolète). La biométrie est utilisée pour déverrouiller l'application, confirmer les paiements et accéder aux données protégées.

Nuances importantes : la biométrie est une UX pratique, mais pas un remplacement de l'authentification serveur. Après une vérification biométrique réussie, l'application doit obtenir un jeton d'accès du serveur. Sur Android, assurez-vous de vérifier que l'appareil utilise la biométrie de Classe 3 (Forte), pas seulement la reconnaissance faciale basée sur caméra (Classe 1).

Protection du Code : ProGuard, R8 et Root Detection

Obfuscation : ProGuard et R8

ProGuard est un outil d'obfuscation, de compression et d'optimisation du bytecode Java pour Android, renforçant la sécurité du code contre la rétro-ingénierie. R8 est son successeur, intégré dans Gradle depuis Android Studio 3.4. R8 effectue quatre tâches : compression (supprime les classes et méthodes inutilisées), optimisation (inline les méthodes, simplifie le code), obfuscation (renomme les classes et méthodes en noms courts) et pré-vérification (vérification du bytecode).

DexGuard est une version commerciale de ProGuard avec une protection renforcée : chiffrement des chaînes, obfuscation des ressources, protection contre le reconditionnement, contrôle d'intégrité de l'APK. Pour la plupart des projets, R8 est suffisant, mais pour les applications financières et bancaires, DexGuard offre une couche de sécurité supplémentaire. R8 est activé via build.gradle : minifyEnabled = true et proguardFiles.

Détection Root et Jailbreak

Root Detection (Android) et Jailbreak Detection (iOS) sont des mécanismes qui vérifient si des privilèges superutilisateur ont été obtenus sur l'appareil. Sur les appareils compromis, il est possible de lire la mémoire du processus, d'intercepter le trafic et de substituer du code. Pour la vérification sur Android, on utilise la présence du binaire SU, des clés de signature de test et des flags de build non standard.

RASP (Runtime Application Self-Protection) est une technologie qui protège l'application pendant l'exécution. RASP détecte les tentatives de débogage, de reconditionnement, d'injection de code et termine l'application lorsque des menaces sont détectées. Exemples de solutions RASP : Dexter, Guardsquare, Promon. RASP fonctionne à l'exécution et réagit aux anomalies — contrairement à l'obfuscation statique, qui protège le code avant l'exécution.

Rétro-Ingénierie est le processus de récupération du code source à partir d'une application compilée. Outils : JADX (décompilateur APK), Ghidra, IDA Pro, Hopper. La protection contre la Rétro-Ingénierie est une combinaison d'obfuscation, de chiffrement des chaînes, de vérification d'intégrité et de Root Detection. Il n'existe pas de protection complète — l'objectif est de rendre la rétro-ingénierie suffisamment coûteuse pour l'attaquant.