Chapitre 8 (suite) — Injection SQL
⏱ ~30 min autonome · ~45 min encadré
L'injection SQL reste, des décennies après sa découverte, l'une des vulnérabilités web les plus fréquentes et les plus dommageables — non pas parce qu'elle est difficile à corriger, mais parce que la correction exige une discipline systématique plutôt qu'un correctif ponctuel.
- Expliquer le principe de fonctionnement d'une injection SQL.
- Distinguer injection en bande, aveugle et hors bande.
- Appliquer le principe des requêtes préparées comme contre-mesure structurelle.
Une application web mal conçue construit parfois ses requêtes vers la base de données en insérant directement une entrée utilisateur dans une chaîne de caractères SQL, sans distinction entre « donnée » et « commande ». Si cette entrée contient elle-même des instructions SQL valides, la base de données les exécute comme si elles faisaient partie de la requête légitime — l'attaquant a effectivement injecté sa propre logique dans celle de l'application.
| Type | Principe |
|---|---|
| En bande (in-band) | Le résultat de l'injection est directement visible dans la réponse de l'application — le canal d'attaque et le canal de résultat sont les mêmes. La forme la plus simple à exploiter et à détecter. |
| Aveugle (blind) | Aucun résultat n'est directement affiché, mais l'attaquant déduit de l'information à partir du comportement de l'application — une réponse différente selon qu'une condition est vraie ou fausse, ou un délai de réponse volontairement provoqué. |
| Hors bande (out-of-band) | Le résultat est exfiltré via un canal totalement différent de celui de la requête (une requête DNS ou HTTP déclenchée vers un serveur contrôlé par l'attaquant) — utilisée quand ni l'injection en bande ni l'aveugle ne sont praticables. |
Requêtes préparées
La contre-mesure structurelle de référence : les requêtes préparées (prepared statements) séparent explicitement la structure de la requête SQL (fixée à l'avance) des données fournies par l'utilisateur (toujours traitées comme de simples valeurs, jamais comme du code exécutable) — peu importe ce que contient l'entrée utilisateur, elle ne peut jamais altérer la structure de la commande elle-même.
Validation des entrées
En complément (jamais en remplacement) des requêtes préparées, valider le format attendu d'une entrée (un code postal ne devrait contenir que des chiffres et lettres selon un format précis, par exemple) réduit encore la surface d'attaque, en particulier pour les contextes où une requête préparée classique ne s'applique pas directement (noms de colonnes ou de tables dynamiques, par exemple).
PortSwigger Web Security Academy propose des laboratoires interactifs gratuits en ligne couvrant l'injection SQL sous toutes ses formes (en bande, aveugle, hors bande), alignés sur l'OWASP Top 10. C'est la ressource pratique recommandée pour qui veut s'exercer concrètement au-delà de la théorie couverte ici — ce cours n'inclut volontairement pas de laboratoire pratique en version publique (voir Pour les établissements pour la version avec laboratoires sur mesure).