Injection SQL : définition, exemples et prévention

Comment fonctionne une injection SQL ?

L'attaquant exploite un champ de saisie (formulaire, URL, API) dont les entrées ne sont pas validées. En injectant une chaîne comme ' OR 1=1 --, il modifie la logique de la requête SQL pour contourner l'authentification ou extraire des données.

Impact pour une PME

Une injection SQL réussie peut exposer la totalité de la base clients, les identifiants, les données de paiement ou les documents métier. Pour une PME, c'est un risque de notification CNIL (RGPD), de perte de confiance client et de coût de remédiation élevé.

Comment prévenir les injections SQL ?

• Utiliser des requêtes paramétrées (prepared statements) systématiquement.
• Valider et assainir toutes les entrées utilisateur côté serveur.
• Appliquer le principe du moindre privilège sur les comptes de base de données.
• Tester régulièrement avec un pentest incluant les vecteurs SQLi.

Exemple concret de SQLi

Un formulaire de login utilise la requête suivante côté serveur (PHP/Python) :

sql = "SELECT * FROM users WHERE email='" + email + "' AND pwd='" + pwd + "'"

Un attaquant saisit admin@x.com' -- dans le champ email. La requête devient :

SELECT * FROM users WHERE email='admin@x.com' -- ' AND pwd='...'

Le -- commente le reste. L'attaquant est authentifié comme admin sans connaître le mot de passe. Score CVSS typique : 9.1 (Critique).

Types d'injection SQL

• In-band (classique) : la réponse SQL est renvoyée directement dans la page HTML : la plus facile à détecter.
• Blind SQLi : l'application ne renvoie rien, mais le comportement (temps de réponse, présence d'un élément) dévoile la réponse : exploitable via sqlmap.
• Out-of-band : exfiltration via DNS ou HTTP déclenchée par la base (INTO OUTFILE, xp_cmdshell) : plus rare mais dévastatrice.
• Second-order : le payload est stocké en base puis exécuté lors d'une requête ultérieure : invisible dans les logs de formulaire.

FAQ Injection SQL

Les ORM (Prisma, Sequelize, Hibernate) protègent-ils automatiquement ?

À 95 %, oui. Le risque résiduel vient des $queryRaw, des WHERE construits à la main ou des fonctions de recherche full-text où le développeur concatène.

Un WAF peut-il bloquer toutes les SQLi ?

Non. Un WAF bloque les patterns évidents mais est contournable par encodage (URL, Unicode, commentaires MySQL /*!50000*/). Le code parametrisé reste la seule défense fiable.

Combien coûte une fuite de base clients pour une PME ?

Le coût dépend du périmètre compromis et de l'interruption d'activité ; il ne se déduit pas de l'effectif avec une fourchette universelle. Voir notre article coût cyberattaque PME.

Faut-il tester manuellement les SQLi ou automatiser ?

Les deux. sqlmap détecte les SQLi triviales ; un pentester manuel trouve les second-order et les blind conditionnées au contexte métier. Laucked combine les deux.