En 2024, l'injection SQL représentait 6,7% de toutes les vulnérabilités découvertes dans les projets open source et 10% dans les projets propriétaires. Ce n'est pas un chiffre alarmant en apparence, mais rapporté aux centaines de millions de dollars stockés sur les plateformes crypto, une seule faille suffit. Plus de 20% des projets propriétaires étaient vulnérables au SQL injection lors de leur premier audit de sécurité.
L'injection SQL est l'une des plus vieilles attaques du web. Elle date des années 90. Et elle fonctionne encore en 2025 parce que des développeurs continuent de faire les mêmes erreurs. Dans le monde crypto, où les plateformes gèrent des fonds réels, ces erreurs coûtent très cher.
Comment fonctionne l'injection SQL
La plupart des sites web utilisent des bases de données SQL pour stocker les données : comptes utilisateurs, historique de transactions, soldes. Quand vous vous connectez à un exchange, le site envoie une requête SQL du type "SELECT * FROM users WHERE email='votre@email.com' AND password='votrehash'". L'injection SQL consiste à modifier cette requête en insérant du code SQL dans un champ de saisie.
Exemple basique : au lieu de taper votre email, vous tapez "admin'--". Le tiret double (--) transforme le reste de la requête en commentaire. La requête devient "SELECT * FROM users WHERE email='admin'--' AND password=''". Le mot de passe est ignoré. Vous êtes connecté en tant qu'admin sans connaître le mot de passe.
C'est un exemple simpliste, mais le principe reste le même sur des attaques plus sophistiquées. L'attaquant peut extraire toute la base de données (blind SQL injection), modifier des données, supprimer des tables, ou même exécuter des commandes sur le serveur dans les cas les plus graves.
Les dégâts possibles sur un exchange crypto
Sur un exchange centralisé, une injection SQL peut donner accès à la base de données complète : emails, hashs de mots de passe, informations KYC (photos d'identité, adresses), historique de transactions, et potentiellement les clés de hot wallets si elles sont mal séparées de la base principale.
Avec les emails et les mots de passe hashés, l'attaquant peut lancer des attaques de brute force hors ligne pour retrouver les mots de passe en clair. Combiné avec les données KYC volées, c'est une mine d'or pour l'usurpation d'identité.
En 2024, la majorité des hacks d'exchange ont impliqué des compromissions de clés privées et de hot wallets plutôt que des injections SQL directes. Mais l'injection SQL reste souvent le point d'entrée initial qui permet de comprendre l'architecture interne et de trouver des vecteurs d'attaque plus profonds.
Pourquoi ça existe encore en 2025
La réponse courte : la négligence des développeurs. Les requêtes paramétrées (prepared statements) éliminent le risque d'injection SQL. Elles existent depuis plus de 20 ans. Pourtant, des développeurs continuent d'écrire des requêtes SQL en concaténant des chaînes de caractères avec les entrées utilisateur.
Dans l'écosystème crypto, le problème est amplifié par la vitesse de développement. Les projets lancent leur plateforme le plus vite possible pour capter le marché. La sécurité passe au second plan. "On auditara plus tard" est une phrase que j'ai entendue trop souvent. Le "plus tard" arrive généralement après le hack.
Les frameworks modernes (Django, Rails, Laravel) incluent des protections contre l'injection SQL par défaut. Mais dès qu'un développeur écrit une requête SQL "à la main" pour un cas spécifique, le risque revient. Et sur les plateformes crypto qui gèrent des logiques complexes de trading et de matching d'ordres, les requêtes custom sont fréquentes.
Se protéger en tant qu'utilisateur
Vous ne pouvez pas savoir si un exchange est vulnérable au SQL injection. C'est un problème côté serveur. Mais vous pouvez limiter les dégâts en cas de fuite.
Utilisez un mot de passe unique par exchange. Si la base de données d'un exchange fuite, votre mot de passe ne compromet pas vos autres comptes. Activez la double authentification sur chaque plateforme.
Ne laissez pas de montants importants sur un exchange. Transférez vos fonds vers un hardware wallet après l'achat. Un exchange peut se faire hacker, votre Ledger non (tant que votre seed phrase est en sécurité).
Surveillez les notifications de fuites de données. Des services comme Have I Been Pwned vous alertent si votre email apparaît dans une fuite. Si un de vos exchanges est compromis, changez immédiatement votre mot de passe et vérifiez que la 2FA est active.
Privilégiez les exchanges qui publient des résultats d'audit de sécurité et des proof-of-reserves. Ce n'est pas une garantie absolue, mais un exchange qui investit dans la sécurité est moins susceptible de laisser des failles SQL injection trainer dans son code.
