L’injection SQL en pratique dans un labo légal, pas à pas

Place à la démarche concrète. Vous allez dérouler, dans votre application d’entraînement, la séquence que suit un testeur : observer, déclencher une réaction, confirmer par un test logique, mesurer l’impact, et s’arrêter. Cette leçon reste volontairement centrée sur la méthode et la preuve minimale, car c’est cela que l’on attend d’un professionnel.

Préparer l’expérience

• Réglez DVWA sur le niveau de sécurité le plus bas et ouvrez le module consacré à l’injection SQL.
• Faites passer le trafic par le proxy et repérez la requête émise par le formulaire (un champ qui demande un identifiant d’utilisateur).
• Faites un instantané de la machine virtuelle : vous pourrez revenir à l’état initial.
• Ouvrez votre carnet à une nouvelle entrée, et notez la date, l’application, le niveau de sécurité et le module.

Étape 1 : observer le comportement normal

Saisissez un identifiant valide, par exemple 1. L’application affiche des informations de l’utilisateur correspondant. Notez la forme de la réponse : quels champs, combien de lignes. Saisissez ensuite un identifiant inexistant et observez : message vide ? absence de ligne ? C’est votre référence.

Étape 2 : provoquer une réaction

Envoyez une valeur contenant un caractère de ponctuation SQL, une simple apostrophe. Plusieurs scénarios sont possibles :

À ce stade, vous n’avez rien « attaqué » : vous avez posé une question à l’application et elle a répondu. Consignez la réponse exacte dans le carnet.

Étape 3 : confirmer par un test logique minimal

Un message d’erreur ne prouve pas à lui seul qu’on peut contrôler la requête. Pour confirmer, on compare deux conditions dont on connaît le résultat : une qui est toujours vraie, une qui est toujours fausse, insérées de façon à garder la requête syntaxiquement valide.

• Avec la condition « toujours vraie », la réponse doit être différente de la référence : par exemple, davantage de lignes affichées, puisque le filtre sur l’identifiant ne s’applique plus.
• Avec la condition « toujours fausse », la réponse doit revenir à un résultat vide.

Voici la requête telle que la base la reçoit dans le premier cas, une fois la valeur collée dans le texte (on voit apparaître le principe sans qu’il s’agisse d’une recette adaptée à une cible) :

SELECT prenom, nom FROM utilisateurs WHERE id = '1' OR '1'='1';

La condition '1'='1' est toujours vraie ; comme elle est reliée à la première par OR, la requête renvoie toutes les lignes de la table au lieu d’une seule. Ce comportement, reproductible et différent selon la condition, est la preuve que le paramètre influence la structure de la requête.

Notez une chose importante : on a prouvé la faille avec deux essais, sans toucher à autre chose que la lecture d’un jeu de données fictif d’entraînement.

Étape 4 : mesurer l’impact, sans excès

La question de l’auditeur devient : « que pourrait faire un attaquant réel ici ? ». On y répond par le raisonnement, à partir de ce qu’on observe :

• La page affiche des données personnelles de plusieurs utilisateurs : confidentialité atteinte.
• Le champ est utilisé dans une requête de lecture : la modification de données dépendrait des droits du compte de base.
• Le message d’erreur révèle le type de base de données : divulgation d’informations.

Dans un audit réel, on s’arrête au minimum nécessaire pour établir et illustrer l’impact, et on ne télécharge jamais de données réelles au-delà de la preuve. Si vous découvriez accidentellement des données personnelles réelles, vous devriez cesser immédiatement, ne pas les conserver, et en informer le client (cadre contractuel). Dans DVWA, les données sont fictives : c’est précisément ce qui rend l’exercice légitime.

Étape 5 : documenter

Voici un constat rédigé dans l’esprit attendu :

Constat n° : 07
Application : DVWA (niveau de sécurité bas), laboratoire local
Page : module Injection SQL, paramètre « id »
Observation : une apostrophe provoque une erreur de base de données
détaillée. Deux conditions logiques (vraie / fausse) produisent des
réponses différentes, ce qui confirme que la valeur modifie la requête.
Impact : lecture de données au-delà de celles prévues par la page.
Gravité estimée : élevée.
Correction suggérée : requêtes préparées (paramétrées), compte de base
de données aux droits minimaux, messages d’erreur génériques.

Remarquez que le constat ne contient aucune « charge » à copier : il décrit le comportement et la preuve en termes que le développeur peut vérifier et corriger.

Quand c’est « aveugle »

Si l’application n’affiche aucune erreur, la confirmation reste possible, de manière plus indirecte : une différence de contenu entre deux conditions, ou une différence de temps de réponse. Ces techniques, plus lentes, sont à explorer dans les laboratoires guidés de la PortSwigger Academy, qui détaillent le raisonnement avec des environnements prévus pour. Retenez surtout l’idée : toute différence de comportement reproductible est une information.

Et les outils automatiques ?

Il existe des outils libres qui automatisent la détection et la démonstration d’injections SQL. Ils sont utiles aux professionnels pour gagner du temps, mais ils présentent deux risques : générer un volume de requêtes très élevé et, mal réglés, modifier ou extraire des données. À notre niveau, il est préférable de comprendre le mécanisme à la main avant d’automatiser, et de ne jamais utiliser ces outils hors d’un périmètre autorisé.

À vous de jouer

1. Dans DVWA (niveau bas), suivez les étapes 1 à 3 sur le module d’injection SQL. Consignez la réponse de référence, la réaction à l’apostrophe, et les réponses aux deux conditions logiques.
2. Rédigez le constat complet dans votre carnet en reprenant le modèle ci-dessus.
3. Passez au niveau « moyen » puis « élevé » : décrivez ce qui change dans la requête envoyée et dans les réponses.
4. Réglez le niveau sur « impossible » et expliquez, en lisant le code source proposé par l’application, pourquoi l’injection ne marche plus.

L’injection SQL a des cousines : la leçon suivante élargit la vue aux autres types d’injection.