Le Guide Complet de l'Injection SQL (SQLi) en 2025

L'injection SQL (SQLi) reste l'une des vulnérabilités les plus dévastatrices et les plus exploitées sur Internet aujourd'hui. Bien qu'elle existe depuis plus de deux décennies, l'injection SQL se classe régulièrement dans le peloton de tête du Top 10 de l'OWASP. Dans ce guide complet, nous allons explorer les détails de l'injection SQL, des charges utiles de base aux techniques de contournement avancées, afin d'éduquer les professionnels de la sécurité et les développeurs sur la manière d'empêcher les accès non autorisés aux bases de données.

Qu'est-ce que l'Injection SQL ?

L'injection SQL se produit lorsque les données fournies par l'utilisateur sont interprétées comme du code par la base de données principale. En manipulant les champs de saisie, un attaquant peut modifier la requête SQL prévue, forçant la base de données à exécuter des commandes arbitraires. Cela peut conduire à la divulgation non autorisée de données, à la modification de données ou même à la compromission complète du système. Lorsqu'il s'agit d'applications web, une mauvaise désinfection des entrées est la cause principale de l'injection SQL.

Impact dans le Monde Réel

Une attaque par injection SQL réussie peut avoir des conséquences catastrophiques pour une organisation. Les attaquants peuvent contourner les formulaires d'authentification, extraire la propriété intellectuelle sensible ou vider des bases de données entières de clients contenant des informations personnellement identifiables (IPI). Dans les cas graves, le SQLi peut être exploité pour obtenir l'exécution de code à distance (RCE) via xp_cmdshell dans Microsoft SQL Server ou INTO OUTFILE dans MySQL.

Types d'Injection SQL

1. SQLi en Bande (Classique)

L'injection SQL en bande est la variante la plus simple. L'attaquant utilise le même canal de communication pour lancer l'attaque et recueillir les résultats.

• SQLi Basé sur les Erreurs : L'attaquant force la base de données à générer un message d'erreur qui révèle par inadvertance des informations sur la structure ou la version de la base de données.
• SQLi Basé sur Union : Cette technique tire parti de l'opérateur UNION pour combiner les résultats de la requête d'origine avec les résultats d'une requête malveillante.

2. SQLi Inférentiel (Aveugle)

Dans une attaque par injection SQL aveugle, l'application web ne renvoie pas d'erreurs de base de données ou les résultats de la requête injectée directement à l'écran. L'attaquant doit déduire des informations en posant des questions vrai/faux à la base de données.

• SQLi Aveugle Basé sur les Booléens : L'attaquant envoie une requête SQL qui pose une question (par exemple, "La première lettre du mot de passe de l'administrateur est-elle 'A' ?").
• SQLi Aveugle Basé sur le Temps : Lorsque l'application répond de manière identique quelle que soit la valeur de vérité de la requête, l'attaquant ordonne à la base de données de faire une pause pendant un laps de temps spécifié.

3. SQLi Hors Bande

Le SQLi hors bande est utilisé lorsque l'attaquant ne peut pas utiliser le même canal pour lancer l'attaque et recueillir les résultats.

Charges Utiles Réelles et Techniques de Contournement

Les filtres de sécurité et les pare-feu d'applications web (WAF) tentent souvent de bloquer les charges utiles courantes d'injection SQL.

Contournement de l'Authentification

Une charge utile classique de contournement de l'authentification :

' OR '1'='1

Lorsqu'elle est injectée dans un formulaire de connexion, elle modifie la requête pour qu'elle soit toujours évaluée comme vraie.

Contournement de WAF

1. Variation de la Casse : Si un filtre recherche SELECT, l'utilisation de SeLeCt peut le contourner.
2. Manipulation des Espaces : Remplacement des espaces par des commentaires (/**/).

SELECT/**/password/**/FROM/**/users

Exemples d'Exploitation Réels

Prenons une application PHP vulnérable :

$username = $_POST['user'];
$query = "SELECT * FROM users WHERE username = '$username'";
$result = mysqli_query($conn, $query);

Un attaquant soumet l'entrée suivante pour $username : admin' --

La requête résultante exécutée par la base de données devient :

SELECT * FROM users WHERE username = 'admin' --'

La base de données traite tout ce qui suit -- comme un commentaire.

Prévention et Pratiques de Codage Sécurisé

Le seul moyen fiable de prévenir l'injection SQL est de séparer les données du code.

1. Requêtes Paramétrées (Requêtes Préparées)

Les requêtes paramétrées garantissent que les entrées de l'utilisateur sont traitées strictement comme des données, et non comme du code exécutable.

Exemple en PHP (PDO) :

$stmt = $pdo->prepare('SELECT * FROM users WHERE username = :username');
$stmt->execute(['username' => $username]);
$user = $stmt->fetch();

2. Procédures Stockées

Les procédures stockées peuvent offrir un niveau de protection similaire aux requêtes paramétrées.

3. Validation des Entrées

Mettez en œuvre une validation stricte des entrées.

4. Principe du Moindre Privilège

Configurez les comptes de base de données avec les privilèges minimaux nécessaires.

Lectures Complémentaires

Pour mieux comprendre comment ces vulnérabilités s'intègrent dans des stratégies de sécurité plus larges, vous devriez consulter nos articles sur : - XSS expliqué en détails - Audits de Sécurité

Référez-vous toujours à la base de données de l'OWASP ou au NVD pour les CVE officielles.

Conclusion

L'injection SQL est une vulnérabilité critique qui exige une attention sérieuse de la part des développeurs et des professionnels de la sécurité. En comprenant les mécanismes du SQLi et en appliquant systématiquement des pratiques de codage sécurisé comme les requêtes paramétrées, les organisations peuvent éliminer efficacement cette menace.