Fiche de révision : injections SQL
Mise à jour le 7 août 2026
Le problème : concaténer au lieu de paramétrer
-- Vulnérable : la valeur est concaténée dans le texte SQL
SELECT * FROM utilisateurs WHERE identifiant = '${identifiant}'La protection : une requête préparée
-- Sûr : la valeur est transmise à part, jamais interprétée comme du SQL
SELECT * FROM utilisateurs WHERE identifiant = ?Astuce
Une requête préparée neutralise ' OR '1'='1 aussi bien que UNION SELECT : la base de données traite toujours la valeur fournie comme une donnée brute, jamais comme une instruction.
L'essentiel
Pourquoi une requête SQL construite par concaténation est-elle dangereuse ?
Parce qu'elle mélange le code SQL écrit par le développeur et les données fournies par l'utilisateur : rien ne distingue plus une donnée d'une instruction SQL aux yeux du moteur de base de données.
Que produit la valeur ' OR '1'='1 insérée dans un mot de passe concaténé ?
Une condition WHERE toujours vraie : '1'='1' l'est systématiquement, donc la requête retourne un utilisateur sans que le bon mot de passe ait été fourni.
À quoi sert un commentaire SQL (--) dans une charge d'injection ?
À ignorer le reste de la requête d'origine, y compris une seconde condition qui suivrait la vérification du mot de passe.
Que doit vérifier une injection UNION SELECT pour fonctionner ?
Retourner le même nombre de colonnes que la requête d'origine, avec des types compatibles.
Comment déterminer le nombre de colonnes d'une requête à l'aveugle ?
En incrémentant un ORDER BY jusqu'à provoquer une erreur : une erreur sur ORDER BY N indique que la requête retourne N-1 colonnes.
Comment extraire une donnée quand aucun résultat de requête n'est directement affiché ?
Par injection aveugle : transformer l'extraction en une suite de questions vrai/faux (ex. SUBSTR(valeur, 1, 1) = 's'), en observant une différence de comportement de l'application plutôt qu'un contenu affiché.
Que faire quand même une différence de comportement vrai/faux n'est pas observable ?
Passer à l'injection temporelle : injecter une temporisation (SLEEP, pg_sleep, WAITFOR DELAY selon le moteur) déclenchée uniquement si la condition est vraie, et mesurer le délai de réponse comme signal.
Quelle est la protection efficace contre les injections SQL ?
Les requêtes préparées (paramétrées) : la valeur est transmise séparément du texte SQL, jamais concaténée dans la requête elle-même. Cette protection neutralise indifféremment l'apostrophe, UNION-based et l'injection aveugle.