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, a marqué le début de la civilisation). Il y a eu des milliers de violations causées par l'injection SQL et une quantité infinie de meilleures pratiques et d'outils bien documentés pour aider à la prévenir. Il est donc certain que nous avons tiré les leçons de ces violations et que l'injection SQL n'est plus un problème.

Nous avons surveillé le nombre d'injections SQL découvertes dans des projets open-source et closed-source pour voir si nous nous améliorons. Avec l'annonce récente que les données volées dans le cadre de l'injection SQL de MOVEit sont vendues à des entreprises telles qu'Amazon, nous avons décidé de vous donner un aperçu de notre futur rapport sur l'état des injections pour l'année 2025.

Spoiler, il s'avère que nous sommes toujours aussi mauvais dans la prévention des injections SQL.

Qu'est-ce que l'injection SQL ?

SQLi est une vulnérabilité qui se produit lorsqu'un programme utilise une entrée utilisateur non fiable 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, ce qui lui permet 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 par contournement de l'authentification SQLi.

Il existe de nombreux types d'attaques par injection, comme l'injection de code ou le cross-site scripting (XSS). Mais SQLi joue depuis longtemps un rôle prépondérant dans les brèches et il est choquant de constater qu'il faut encore en parler en 2024.

Comment se produit une attaque SQLi

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

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

3. Requête exécutée avec la charge utile
La charge utile 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 trouvées dans les projets open-source sont des failles SQLi
• 10% pour les projets à code source fermé !
• Une augmentation du nombre total d'injections SQL dans les projets open-source (CVE's qui impliquent SQLi) de 2264 (2023 ) à 2400 (2024) est attendue.
• En pourcentage de toutes les vulnérabilités, l'injection SQL devient 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 à code source fermé analysés sont vulnérables à l'injection 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 s'élève à près de 30 emplacements distincts dans le code.

Nous avons examiné le nombre de vulnérabilités SQLi découvertes dans des paquets open-source en 2023 et jusqu'à présent en 2024. Nous avons ensuite comparé ces chiffres aux projets à code source fermé qui ont été découverts par Aikido Security. Sans surprise, nous constatons toujours un nombre choquant d'injections SQL dans les projets fermés 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 fermés sont des vulnérabilités par injection SQL. Cela peut sembler peu, mais il est franchement choquant qu'en 2024, nous ayons encore du mal à faire face à certaines des vulnérabilités les plus élémentaires que nous connaissions.

La seule bonne nouvelle est que ce chiffre représente une baisse de 14 % par rapport à 2023 dans les projets 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 de SQLi trouvés devrait augmenter de 2264 en 2023 à plus de 2400 à la fin de 2024 dans les projets open-source.

Prévention de l'injection 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. Utiliser des instructions préparées et des requêtes paramétrées

Dans l'exemple présenté au début de ce billet, nous avons montré un code vulnérable parce qu'il prend une entrée utilisateur non fiable et l'utilise directement dans une requête. Pour éviter cela, nous devons utiliser des instructions préparées, ce qui signifie que vous devez d'abord définir votre requête, puis ajouter l'entrée de l'utilisateur plus tard. Cela permet de séparer le flux de commandes et de données, ce qui résout complètement le problème. Une excellente solution, mais qui n'est pas toujours possible ou utilisée !

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/schémas côté serveur

La validation des entrées peut s'avérer efficace pour prévenir les attaques de type SQLi. Par exemple, si votre API attend une adresse électronique ou un numéro de carte de crédit, il est facile d'ajouter une validation pour ces cas.

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

L'un des éléments les plus terrifiants de SQLi est qu'il est facilement découvert par les adversaires, souvent décrit comme une vulnérabilité à portée de main. Cela s'explique en partie par le fait que des outils tels que DAST peuvent les découvrir automatiquement. Cela peut être utilisé à notre avantage et nous pouvons introduire ces outils dans notre processus de développement pour les détecter rapidement.

Les outils SAST de nouvelle génération tels qu'Aikido vous permettent également de résoudre automatiquement les problèmes à partir de la plateforme.

4. Mettre en place un pare-feu intégré à l'application

Un pare-feu in-app surveille le trafic et l'activité à l'intérieur de votre application et peut détecter les attaques, y compris l'injection et SQLi. Il est plus efficace qu'un WAF traditionnel car il se trouve à l'intérieur de votre application et est capable d'identifier les requêtes attendues et de bloquer les requêtes qui modifient la structure de commande de la requête.

Plug sans vergogne ;) pour le nouveau lancement d'Aikido: Zen, le pare-feu in-app pour une tranquillité d'esprit au moment de l'exécution. Obtenez Zen et il bloquera automatiquement les attaques par injection critiques et les menaces de type "zero-day" en temps réel, avant qu'elles n'atteignent votre base de données.

5. Éviter le SQL dynamique dans la mesure du possible

La génération dynamique de code SQL par concaténation de chaînes est très vulnérable aux injections SQL. Dans la mesure du possible, il convient de s'en tenir à des requêtes statiques et prédéfinies et à des procédures stockées qui ne s'appuient pas sur un contenu généré par l'utilisateur pour la structure SQL.

6. Autoriser l'inscription et l'échappement

Dans certains cas, vous ne pouvez pas éviter Dynamic SQL, par exemple lorsque vous interrogez des tables dynamiques ou lorsque vous souhaitez classer les données en fonction d'une colonne et d'une direction définies par l'utilisateur. Dans ces cas-là, vous n'avez pas d'autre choix que de vous fier à la liste d'autorisations des expressions régulières ou à l'échappement. L'échappement consiste à prendre les données de l'utilisateur qui contiennent 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 avant les caractères, soit en les transformant en un code de symboles. Notez que cela diffère 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.

Verrons-nous un jour la fin de SQLi ?

Bien que le fait que nous ayons constaté une diminution significative du nombre de vulnérabilités SQLi soit prometteur, il est toujours décourageant de voir qu'une vulnérabilité antérieure au jeu DOOM constitue toujours une menace aussi importante. En vérité, je ne vois pas comment la situation pourrait s'améliorer. Alors que nous introduisons de plus en plus d'outils pour nous aider à coder plus rapidement, les développeurs sont de moins en moins en contact avec les principes de base du codage et ces outils d'IA sont notoirement mauvais pour suggérer des codes vulnérables, y compris des vulnérabilités d'injection.

Nous constatons des améliorations significatives dans une nouvelle génération d'outils SAST qui sont beaucoup plus efficaces pour découvrir et corriger ces vulnérabilités et qui ont la capacité de changer radicalement le paysage des menaces.

En signant pour l'instant, n'oubliez pas de.. :

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

Checkout Zen et prévenir les attaques par injection au fur et à mesure qu'elles se produisent

Bonus : L'histoire de SQL à travers l'histoire

Depuis que nous avons commencé à parler de sécurité dans nos applications, nous avons parlé de l'injection SQL. Elle figurait même en 7e position dans le tout premier top 10 de l'OWASP en 2003. En 2010, elle a été incluse dans la catégorie des injections et a pris la première place jusqu'en 2021. L'une des premières attaques à grande échelle documentées impliquant l'injection SQL a eu lieu lorsque l'entreprise de vêtements Guess a été prise pour cible, ce qui a entraîné la fuite de numéros de cartes de crédit. Depuis lors, l'injection SQL fait régulièrement la une des journaux de sécurité.

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