L’injection SQL expliquée simplement

C’est quoi, au juste ?

Votre site pose en permanence des questions à sa base de données : « donne-moi le produit n°42 », « ce mot de passe correspond-il à cet utilisateur ? ». Ces questions sont écrites en langage SQL.

Le problème apparaît quand le site fabrique la question en y collant directement du texte tapé par le visiteur. Un visiteur malin ne se contente pas de répondre : il glisse un bout de question à lui. C’est comme laisser quelqu’un compléter la phrase que vous alliez dire au coffre-fort.

Un exemple concret

Imaginez une page produit : app.exemple.fr/produit?id=42. En coulisses, le site demande « le produit dont l’id vaut 42 ». Si l’attaquant remplace 42 par 42 OR 1=1, la question devient « le produit dont l’id vaut 42 OU vrai » — et la base peut renvoyer TOUS les produits.

Des variantes plus discrètes ne renvoient rien de visible, mais font « attendre » la base quelques secondes selon la réponse. En mesurant ce délai, l’attaquant lit votre base lettre par lettre, sans jamais l’afficher.

Pourquoi c’est grave

Une injection SQL exploitable donne souvent accès à toute la base : comptes, mots de passe, e-mails, commandes de vos clients. Parfois, elle permet de se connecter en administrateur sans mot de passe, voire de prendre le contrôle du serveur.

C’est l’une des failles les plus anciennes et pourtant toujours dans le Top 10 OWASP (catégorie A03:2021 – Injection), parce qu’il suffit d’un seul champ oublié pour tout ouvrir.

Comment s’en protéger

La règle d’or : ne jamais coller le texte du visiteur dans une requête SQL. On utilise des requêtes préparées (dites « paramétrées ») : on écrit la question avec des trous, et on passe les valeurs à part. La valeur ne peut alors plus modifier la structure de la question.

Concrètement : en PHP/PDO, prepare("SELECT * FROM produits WHERE id = ?") puis execute([$id]). En Python, cur.execute("… WHERE id = %s", (id,)). Ajoutez un typage strict (un id doit être un nombre) et un compte base au moindre privilège. En production, masquez les messages d’erreur SQL détaillés.

Comment SauronSec la détecte

SauronSec envoie des sondes bénignes sur chaque paramètre, en-tête, cookie et champ JSON, puis mesure la réaction. Un délai qui croît proportionnellement à la charge (0→3s, 6→6s) trahit une vraie injection — une simple lenteur réseau, elle, ne suit pas la charge.

Surtout, chaque candidat est rejoué deux fois et comparé à une réponse de référence. Ce qui ne se reproduit pas est écarté : c’est ainsi qu’on obtient zéro faux positif. Vous ne recevez que des failles réelles, avec la preuve et le correctif.