L'état de l'injection SQL

L'injection SQL (SQLi) a une histoire plus ancienne qu'Internet Explorer (qui, selon la génération Z, marquait le début de la civilisation). Des milliers de violations ont été causées par l'injection SQL, et il existe une quantité infinie de bonnes pratiques et d'outils bien documentés pour l'éviter. Il est donc certain que nous avons tiré les leçons de ces violations et que la SQLi n'est plus un problème.

Nous surveillons le nombre d'injections SQL découvertes dans les projets open-source et closed-source pour voir si nous nous améliorons. Avec les récentes nouvelles indiquant que les données volées lors de la faille d'injection SQL MOVEit sont vendues à des entreprises comme Amazon, nous avons décidé de vous donner un aperçu de notre prochain rapport sur l'état des injections pour 2025.

Spoiler, il s'avère que nous sommes toujours très mauvais pour prévenir les injections SQL.

Qu'est-ce que l'injection SQL ?

La SQLi est une vulnérabilité qui se produit lorsqu'un programme utilise des entrées utilisateur non fiables directement dans une requête vers une base de données SQL. Un utilisateur malveillant peut alors insérer son propre code et manipuler la requête, lui permettant d'accéder à des données privées, de contourner l'authentification ou de supprimer des données. L'exemple ci-dessous montre comment une requête SQL non sécurisée pour une page de connexion utilisateur est vulnérable à une attaque de contournement d'authentification par SQLi.

Il existe de nombreux types d'attaques par injection, comme l'injection de code ou le cross-site scripting (XSS). Mais l'injection SQL (SQLi) a spécifiquement joué un rôle prépondérant dans les violations de données pendant très longtemps, et il est choquant pour beaucoup que nous devions encore en discuter en 2024.

Comment se produit une attaque SQLi

1. Requête vulnérable
Exemple de requête vulnérable où l'entrée utilisateur est directement utilisée dans la requête

2. Attaque par injection SQL
Du SQL est injecté dans le champ de saisie utilisateur d'une page d'authentification

3. Exécution de la requête avec payloadLe payload commente la vérification du mot de passe, de sorte que la requête ignore cette étape

L'injection SQL en chiffres :

• 6,7 % de toutes les vulnérabilités détectées dans les projets open source sont des SQLi
• 10 % pour les projets closed-source !
• Une augmentation du nombre total d'injections SQL dans les projets open source (CVE’s impliquant des SQLi) de 2264 (2023) à 2400 (2024) est attendue.
• En pourcentage de toutes les vulnérabilités, l'injection SQL est moins populaire : une diminution de 14 % et 17 % pour les projets open source et closed source respectivement de 2023 à 2024.
• Plus de 20 % des projets closed source analysés sont vulnérables aux injections SQL lorsqu'ils commencent à utiliser des outils de sécurité.
• Pour les organisations vulnérables aux injections SQL, le nombre moyen de sites d'injection SQL est de près de 30 emplacements distincts dans le code.

Nous avons examiné le nombre de vulnérabilités SQLi découvertes dans les packages open-source en 2023 et jusqu'à présent en 2024. Nous avons ensuite comparé cela aux projets closed-source qui ont été découverts par Aikido Security. Sans surprise, nous constatons toujours un nombre choquant d'injections SQL dans les projets closed-source et open-source. 6,7 % de toutes les vulnérabilités découvertes dans les projets open-source en 2024 sont des vulnérabilités par injection SQL, tandis que 10 % des vulnérabilités découvertes dans les projets closed-source étaient des vulnérabilités par injection SQL. Cela peut ne pas sembler beaucoup, mais il est franchement choquant qu'en 2024, nous ayons encore du mal à gérer certaines des vulnérabilités les plus fondamentales que nous connaissons.

La seule bonne nouvelle que nous ayons est que ce nombre représente une diminution de 14 % par rapport à 2023 dans l'open-source et une réduction de 17 % dans les projets closed-source en pourcentage de toutes les vulnérabilités trouvées. Cependant, le nombre total d'injections SQL découvertes devrait passer de 2264 en 2023 à plus de 2400 d'ici fin 2024 dans les projets open-source.

Prévention des injections SQL

Apparemment, il n'y a pas encore assez d'informations sur internet sur la manière de prévenir les injections SQL, voici donc un aperçu des options disponibles en 2025 :

1. Utilisez des requêtes préparées et des requêtes paramétrées

Dans l'exemple présenté au début de cet article de blog, nous avons illustré un code vulnérable qui intègre directement une entrée utilisateur non fiable dans une requête. Pour éviter cela, il est recommandé d'utiliser des requêtes préparées (prepared statements), ce qui implique de définir la requête en premier lieu, puis d'y ajouter les entrées utilisateur. Cette méthode sépare le flux de commande du flux de données, résolvant ainsi le problème de manière complète. Une excellente solution, mais pas toujours réalisable ou mise en œuvre !

import sqlite3
conn = sqlite3.connect('example.db')
cursor = conn.cursor()
user_id = 5  # Exemple d'entrée sécurisée
# Requête sécurisée utilisant une requête paramétrée

cursor.execute("SELECT * FROM users WHERE id = ?", (user_id))

2. Validation des entrées/du schéma côté serveur

La validation des entrées peut être efficace pour prévenir les injections SQL (SQLi). Par exemple, si votre API attend une adresse e-mail ou un numéro de carte de crédit, il est facile d'ajouter une validation pour ces cas.

3. Utilisez les outils SAST et DAST pour découvrir les SQLi

L'un des aspects les plus redoutables des SQLi est qu'elles sont facilement découvertes par les adversaires, souvent décrites comme des vulnérabilités « low-hanging fruit ». Cela est en partie dû au fait que des outils comme DAST peuvent les détecter automatiquement. Nous pouvons utiliser cela à notre avantage et introduire ces outils dans notre processus de développement pour les identifier précocement.

Les outils SAST de nouvelle génération comme Aikido vous permettent également d'autocorriger les problèmes directement depuis la plateforme.

4. Implémentez un pare-feu intégré à l’application

Un pare-feu intégré à l’application surveille le trafic et l'activité au sein de votre application et peut détecter les attaques, y compris les injections et les SQLi. C'est plus efficace qu'un WAF traditionnel, car il est intégré à votre application et est capable de tokeniser les requêtes attendues et de bloquer les demandes qui modifient la structure de commande de la requête.

Petit coup de pub ;) pour le nouveau lancement d'Aikido : Zen, le pare-feu intégré à l’application pour une tranquillité d'esprit en temps d'exécution. Adoptez Zen et il bloquera automatiquement les attaques par injection critiques et les menaces zero-day en temps réel, avant qu'elles n'atteignent votre base de données.

5. Éviter le SQL dynamique lorsque c'est possible

La génération dynamique de SQL par concaténation de chaînes de caractères est très vulnérable aux injections SQL. Dans la mesure du possible, privilégiez les requêtes statiques et prédéfinies ainsi que les procédures stockées qui ne dépendent pas du contenu généré par l'utilisateur pour la structure SQL.

6. Mise en liste blanche et échappement

Dans certains cas, vous ne pouvez pas éviter le SQL dynamique, par exemple lors de l'interrogation de tables dynamiques, ou lorsque vous souhaitez trier par une colonne et une direction définies par l'utilisateur. Dans ces cas, vous n'avez d'autre choix que de vous fier à l'allowlisting par expression régulière ou à l'échappement.  L'échappement consiste à prendre une entrée utilisateur qui contient des caractères dangereux utilisés dans le code, comme « > », et à les transformer en une forme sûre. Soit en ajoutant des barres obliques inverses devant eux, soit en les transformant en un code de symbole. Notez que cela est différent non seulement pour chaque type de base de données, mais peut également dépendre des paramètres de connexion tels que le jeu de caractères.

Verra-t-on un jour la fin des injections SQL ?

Bien qu'il y ait un certain espoir dans le fait que nous ayons constaté une diminution assez significative du nombre de vulnérabilités SQLi, il est toujours décourageant de voir qu'une vulnérabilité antérieure au jeu DOOM représente encore une menace aussi importante pour le paysage. La vérité est que je ne vois pas cela s'améliorer beaucoup. À mesure que nous introduisons davantage d'outils pour nous aider à coder plus rapidement, les développeurs sont de moins en moins en contact avec les principes fondamentaux du codage, et ces outils d'IA sont notoirement mauvais pour suggérer du code vulnérable, y compris des vulnérabilités par injection.

Cependant, tout n'est pas si sombre (jeu de mots intentionnel) ; nous constatons des améliorations significatives dans une nouvelle génération d'outils SAST qui sont bien plus efficaces pour découvrir et corriger ces vulnérabilités, ce qui a la capacité de changer radicalement le paysage des menaces.

Pour l'instant, n'oubliez pas de :

Découvrez et corrigez automatiquement les injections SQL avec Aikido AI SAST Autofix

Découvrez Zen et prévenez les attaques par injection dès qu'elles se produisent

Bonus : L'histoire de SQL à travers le temps

Depuis que nous avons commencé à parler de sécurité dans nos applications, nous avons abordé l'injection SQL. Elle figurait même à la 7e place du tout premier Top 10 OWASP en 2003, puis a été incluse dans la catégorie injection en 2010 et a occupé la 1ère place jusqu'en 2021. L'une des premières attaques à grande échelle documentées impliquant une injection SQL a ciblé l'entreprise de vêtements Guess, entraînant la fuite de numéros de carte de crédit. Depuis lors, l'injection SQL est un invité régulier des titres de l'actualité de la sécurité.

Bonus Partie 2 - Consultez Injection Attacks 101 pour obtenir une introduction aux injections SQL, aux injections de code et au XSS