Le principe des injections SQL

Une requête, deux origines

Une application web qui interroge une base de données construit presque toujours sa requête SQL à partir de deux sources : du texte fixe écrit par le développeur, et une valeur fournie par l’utilisateur (un champ de formulaire, un paramètre d’URL, un en-tête HTTP).

Le problème apparaît quand ces deux sources sont assemblées par simple concaténation de chaînes de caractères, sans distinction entre « ce qui est du code » et « ce qui est une donnée ».

-- Requête construite par concaténation
SELECT * FROM produits WHERE id = ' + idFourniParUtilisateur + '

Tant que idFourniParUtilisateur contient un nombre, la requête se comporte comme prévu. Mais rien n’empêche cette valeur de contenir autre chose : du SQL.

Contexte texte, contexte numérique

Le chapitre suivant construit son premier exemple autour d’une apostrophe, parce que la valeur y est délimitée par des guillemets simples (un contexte texte). Mais un champ numérique, laissé sans guillemets dans la requête, est tout aussi vulnérable, et parfois plus simple à exploiter : il n’y a alors aucun délimiteur à refermer.

-- Contexte numérique, sans guillemets
SELECT * FROM produits WHERE id = 1 OR 1=1

Il suffit ici d’ajouter directement une clause après le nombre attendu : 1 OR 1=1 transforme la condition id = 1 en une condition toujours vraie, sans qu’aucune apostrophe n’ait été nécessaire.

Où se cachent ces points d’entrée

Toute donnée qui traverse la frontière entre l’utilisateur et la base de données est un point d’entrée potentiel :

• Champs de formulaire : un champ de connexion, de recherche ou de commentaire, dès lors que sa valeur finit dans une requête.
• Paramètres d’URL : un identifiant transmis en paramètre (?id=42) est aussi exposé qu’un champ de formulaire.
• En-têtes HTTP : moins visibles, mais tout aussi exploitables si leur valeur est réutilisée dans une requête (User-Agent, cookies, etc.).