Ta première injection SQL

Une page de connexion vulnérable

Prenons un formulaire de connexion classique. Le serveur reçoit un identifiant et un mot de passe, puis construit la requête suivante :

SELECT * FROM utilisateurs
WHERE identifiant = 'ALICE' AND mot_de_passe = 'motdepasse123'

Si un utilisateur correspondant existe, l’application considère la connexion réussie. Tant que les deux valeurs viennent directement d’un formulaire sans validation, elles peuvent contenir n’importe quel caractère — y compris une apostrophe, qui referme prématurément la chaîne de texte SQL.

Refermer la chaîne plus tôt que prévu

Imaginons que le champ mot de passe contienne la valeur suivante :

' OR '1'='1

Une fois insérée dans le gabarit de requête, elle produit :

SELECT * FROM utilisateurs
WHERE identifiant = 'ALICE' AND mot_de_passe = '' OR '1'='1'

La condition '1'='1' est toujours vraie, quel que soit l’identifiant. La clause WHERE devient donc systématiquement vraie, et la requête retourne un utilisateur — sans que le bon mot de passe ait été fourni.

Essaie-le toi-même : saisis ' OR '1'='1 dans le champ ci-dessous et observe la requête se construire, puis exécute-la sur une vraie base en mémoire.

SELECT * FROM utilisateurs WHERE identifiant = 'ALICE' AND mot_de_passe = '{valeur}'

Le rôle des commentaires SQL

Une variante fréquente ajoute un commentaire SQL (-- ou #) pour neutraliser le reste de la requête d’origine, notamment quand une seconde condition suit la vérification du mot de passe :

ALICE'--

Tout ce qui suit -- sur la ligne est ignoré par le moteur SQL. Le mot de passe attendu n’est alors même plus évalué.