Réponse.

Les requêtes paramétrées permettent de passer des valeurs dans une requête par le biais de paramètres spéciaux, et non directement par la substitution de variables. Cela améliore la sécurité et protège contre les injections SQL, tout en accélérant l'exécution des requêtes répétitives grâce à la mise en cache des plans.

Le SQL dynamique permet de construire et d'exécuter des requêtes à la volée (par exemple, via EXEC sp_executesql dans MS SQL ou PREPARE/EXECUTE dans PostgreSQL). Il est nécessaire d'être très prudent : la substitution des valeurs directement dans le texte de la requête peut conduire à des injections SQL, des erreurs de syntaxe et une mauvaise performance.

Exemple de requête paramétrée (en Python avec la bibliothèque psycopg2) :

cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

Exemple de SQL dynamique dans PostgreSQL :

EXECUTE format('SELECT * FROM %I WHERE value = %L', tablename, value);

Question piège.

Question : Pourquoi simplement échapper les guillemets ('), comme le font certaines anciennes applications, n'est-il pas suffisant pour se protéger contre les injections SQL ?

Réponse :

Échapper les guillemets ne protégera pas contre tous les types d'injections, surtout si un attaquant injecte une structure de requête SQL (par exemple, "; DROP TABLE users;"). De plus, cela ne couvre pas toutes les spécificités des différents types de données et ne protège pas contre le contournement des filtres via des encodages ou des caractères spéciaux. Il faut toujours utiliser des requêtes paramétrées.

---

Histoire

Dans un des systèmes de calcul des salaires, le SQL dynamique générait des rapports. En raison du manque de prise en charge de la paramétrisation dans l'ancien framework, des chaînes étaient fusionnées manuellement. Un utilisateur a accidentellement (ou pas tout à fait) transmis un fragment SQL dans le champ "nom de famille" - cela a permis d'accéder aux salaires d'autres personnes.

Histoire

Une petite boutique en ligne utilisait du SQL dynamique pour filtrer les produits sans validation adéquate. Lorsqu'un utilisateur tentait de spécifier une valeur non standard, une erreur de parsing SQL était déclenchée, ce qui a temporairement "tué" l'affichage de tous les produits.

Histoire

Dans un CRM, la lettre “O'Connor” a provoqué une erreur dans l'application générant des requêtes SQL par simple addition de chaînes. En raison de l'absence d'échappement d'apostrophes, aucune fiche portant ce nom de famille n'a pu être sauvegardée, ce qui n'a été découvert qu'un an plus tard.