7. Détecter les injections SQL dans une application

Après avoir étudié le déroulement complet d’une attaque par injection SQL, nous abordons désormais le volet défensif du cours, en commençant par la détection. Savoir identifier les points d’entrée vulnérables d’une application est la première étape indispensable avant de pouvoir les corriger.

Les tests manuels de base

Le test le plus simple consiste à injecter une apostrophe simple dans chaque paramètre accessible (champ de formulaire, paramètre d’URL, en-tête HTTP, cookie) et à observer la réaction de l’application. Une erreur SQL affichée en clair dans la page, un message générique inhabituel, ou un comportement différent de la normale constituent tous des indices de vulnérabilité potentielle.

Les messages d’erreur révélateurs

Une application mal configurée affiche parfois directement le message d’erreur renvoyé par le moteur de base de données, qui peut révéler la syntaxe exacte de la requête, le nom du moteur utilisé, voire des fragments du schéma de la base. Ces messages constituent une mine d’informations précieuse tant pour l’attaquant que pour l’auditeur de sécurité.

Les outils d’analyse statique du code (SAST)

Les outils de SAST (Static Application Security Testing) analysent le code source d’une application sans l’exécuter, à la recherche de motifs dangereux comme la concaténation directe de variables dans une requête SQL. Ils permettent de repérer les failles potentielles dès la phase de développement, avant même la mise en production.

Les outils d’analyse dynamique (DAST)

À l’inverse, les outils de DAST (Dynamic Application Security Testing) testent l’application en cours d’exécution, en envoyant automatiquement de nombreuses charges utiles sur chaque paramètre détecté, de façon similaire à ce que fait sqlmap, mais de manière plus exhaustive et systématique sur l’ensemble de l’application.

La surveillance côté base de données

Certains systèmes de gestion de bases de données proposent des journaux d’audit détaillés, permettant de repérer a posteriori des motifs de requêtes anormaux : requêtes contenant des commentaires SQL inhabituels, des clauses UNION inattendues, ou un volume de requêtes erronées anormalement élevé sur une courte période.

Le rôle du pare-feu applicatif (WAF)

Un pare-feu applicatif web (Web Application Firewall) peut être configuré pour détecter et bloquer en temps réel les motifs de requêtes HTTP caractéristiques d’une tentative d’injection SQL, avant même que la requête n’atteigne l’application. Il constitue une couche de détection et de protection complémentaire, mais ne remplace jamais une correction du code à la source.

L’audit de code régulier

Au-delà des outils automatisés, la relecture manuelle du code par un pair ou un auditeur externe reste une méthode de détection précieuse, en particulier pour repérer des constructions de requêtes complexes ou dynamiques que les outils automatisés peinent parfois à analyser correctement.