Les pare-feu d'applications web (WAF) sont souvent présentés comme une barrière infranchissable contre les injections SQL. Cependant, l'analyse des vecteurs d'attaque modernes révèle que les règles statiques et l'analyse syntaxique superficielle présentent des failles exploitables. Les attaquants exploitent les divergences d'interprétation entre le WAF et le serveur backend pour injecter du code malveillant. Voici une analyse technique des mécanismes de contournement et des architectures de défense associées.

Analyse des vulnérabilités intrinsèques des WAF

Les WAF s'appuient principalement sur des moteurs de règles (expressions régulières) et une analyse syntaxique basique. Cette approche souffre de trois limites majeures :

• Obsolescence des signatures : L'incapacité à détecter les nouvelles techniques d'obfuscation sans mise à jour manuelle des règles.
• Divergences d'analyse protocolaire : Le WAF et le serveur d'application peuvent interpréter différemment les requêtes HTTP malformées ou encodées.
• Angles morts contextuels : Difficulté à analyser le contexte métier ou les flux internes non chiffrés.

8 Vecteurs techniques de contournement

1. Manipulation des couches protocolaires

Encodage par morceaux (Chunked Encoding) : En divisant la charge utile (payload) en plusieurs blocs via Transfer-Encoding: chunked, le WAF peut échouer à reconstituer la requête complète avant analyse.

POST /api/v2/authenticate HTTP/1.1
Transfer-Encoding: chunked

8
user_adm
7
in' OR 
4
1=1-
0

Pollution de paramètres HTTP (HPP) : Injecter plusieurs fois le même paramètre peut tromper le WAF qui n'inspecte que la première occurrence, tandis que le backend traite la dernière.

GET /search?query=legitimate_text&query=UNION SELECT version(),2,3 HTTP/1.1

2. Obfuscation syntaxique SQL

Les attaquants modifient la représentation textuelle des mots-clés SQL sans altérer leur exécution par le SGBD.

• Encodage multiple : Utilisation d'URL encoding, Unicode, ou hexadécimal (ex: 0x73656C656374 pour select).
• Insertion de commentaires : UN/**/ION SE/**/LECT.
• Substitution de fonctions : Remplacer SUBSTR() par MID() ou utiliser des opérateurs logiques alternatifs.

3. Exploitation des spécificités des SGBD

Chaque moteur de base de données possède des fonctionnalités uniques pouvant être détournées.

MySQL : Utilisation de la syntaxe avec accolades ou des commentaires conditionnels de version.

SELECT{z 1}; 
/*!50000 UNION*/ SELECT database();

PostgreSQL / SQL Server : Injection de caractères nuls (%00) pour tronquer la chaîne analysée par le WAF, ou utilisation de fonctions de conversion comme CHR() pour reconstruire les mots-clés interdits.

4. Saturation des limites de ressources

Dépassement de capacité d'analyse : Envoyer un payload massivement gonflé avec des caractères de remplissage peut provoquer un dépassement de mémoire tampon dans le moteur d'inspection du WAF.

UNION SELECT 1,2,3 FROM credentials-- [padding de 5000 caractères 'A']

Contournement du Rate Limiting : Utiliser des fonctions de temporisation pour extraire des données bit par bit sans déclencher les alertes de fréquence.

IF(ASCII(SUBSTRING((SELECT password FROM admins LIMIT 1),1,1))>100, pg_sleep(3), 0)

5. Automatisation et évasion des signatures

Les outils d'injection utilisent des scripts de modification (tamper) pour altérer les payloads à la volée et changer les signatures réseau.

sqlmap -u "https://target.local/item?id=5" --tamper=between,randomcase --random-agent

6. Contournement par l'architecture réseau

Plutôt que d'attaquer le WAF frontal, les assaillants cherchent à le contourner :

• Résolution de l'IP réelle : Utilisation de l'historique DNS ou de services tiers pour trouver l'IP d'origine non protégée par le CDN/WAF.
• Attaques sur le réseau interne : Exploitation de failles SSRF pour atteindre des bases de données ou des APIs internes non filtrées.

7. Altération des en-têtes HTTP

Modifier le Content-Type (par exemple, passer de application/x-www-form-urlencoded à multipart/form-data ou application/json) peut désactiver certains modules d'inspection du WAF qui ne parsent pas tous les formats de manière approfondie.

8. Failles logiques et double encodage

Le double encodage URL (ex: %2527 qui devient %27 puis ') exploite les différences de décodage entre le WAF (qui s'arrête au premier niveau) et l'application backend (qui décode une seconde fois).

Mise en pratique : Chaîne d'exploitation complète

Considérons un point d'entrée vulnérable de type numérique sur une API REST, où les mots-clés UNION et SELECT sont bloqués par le WAF.

Étape 1 : Identification du filtrage

L'injection de 1 UNION SELECT 1 retourne une erreur 403. Le filtrage est basé sur les mots-clés standards.

Étape 2 : Contournement par commentaires et casse

Insertion de commentaires inline et mélange de la casse :

1 uNiOn/**/SeLeCt 1,2,3

Étape 3 : Évasion finale avec encodage partiel

Si le WAF détecte encore la requête, on encode partiellement les fonctions d'extraction :

-1 uNiOn/**/SeLeCt 1,%76%65%72%73%69%6f%6e(),3-- 

Cette combinaison permet d'extraire la version du SGBD sans déclencher les règles de signature.

Stratégies de défense en profondeur

1. Sécurisation au niveau du code source

La prévention primaire repose sur l'utilisation exclusive de requêtes paramétrées, éliminant ainsi la concaténation de chaînes.

// Exemple avec Node.js et le driver pg (PostgreSQL)
const queryText = 'SELECT username, email FROM accounts WHERE account_id = $1 AND status = $2';
const values = [req.params.id, 'ACTIVE'];

const res = await pool.query(queryText, values);

Il est également crucial de valider strictement les entrées (whitelisting) et d'appliquer le principe du moindre privilège aux types de données.

2. Optimisation de la configuraton du WAF

• Analyse sémantique : Activer les moteurs capables de comprendre la structure SQL plutôt que de simples correspondances de chaînes.
• Validation stricte du protocole : Rejeter les requêtes avec des en-têtes malformés, des encodages chunked suspects ou des longueurs excessives.
• Mise à jour continue : Intégrer des flux de menaces (Threat Intelligence) pour mettre à jour les règles en temps réel.

3. Durcissement de l'infrastructure

• Isolation réseau : Placer les bases de données dans un sous-réseau privé strict, inaccessible directement depuis Internet.
• Gestion des identités : Révoquer les droits d'administration de la base de données pour l'application. Désactiver les fonctions dangereuses comme LOAD_FILE() ou xp_cmdshell.

4. Détection et réponse (SOC)

• Corrélation des logs : Surveiller les pics de requêtes 403, les temps de réponse anormaux (indicatifs d'injections en aveugle) et les accès aux fichiers sensibles.
• Leurre (Honeypot) : Déployer de fausses tables ou de faux paramètres (ex: admin_debug=true) pour identifier et bloquer les tentatives de reconnaissance.