Qu'est-ce que Injection SQL ?

Attaque qui exploite une application web qui construit des instructions SQL en concaténant simplement les saisies des utilisateurs : la saisie sert à changer le sens de la commande pour manipuler la base de données sans autorisation. Les requêtes préparées avec paramètres substituables (placeholders) sont la contre-mesure fondamentale.

Nom japonais: SQLインジェクション

« Injection SQL » apparaît dans 3 questions d'entraînement réparties sur 1 thèmes, dont Bases de la sécurité de l'information.

Domaine: Bases de la sécurité de l'information

Fonctionnement de l'attaque

Si une application construit une instruction SQL en concaténant des chaînes comme « … WHERE name = ' », la valeur saisie et « ' », une apostrophe dans la saisie ferme la chaîne, et ce qui suit est interprété comme des commandes SQL. Avec la saisie classique ' OR '1'='1, la condition toujours vraie « ou '1' est égal à '1' » est ajoutée, ce qui permet de contourner l'authentification. L'attaque peut aussi conduire à la lecture, à la modification ou à la suppression de données.

La contre-mesure fondamentale

La contre-mesure fondamentale est l'utilisation de requêtes préparées avec paramètres substituables (requêtes paramétrées). La structure de l'instruction SQL est fixée d'abord, et la saisie n'y est rattachée ensuite que comme valeurs ; quels que soient les caractères qu'elle contient, elle ne devient jamais une partie d'une commande. Les bibliothèques d'accès aux bases de données et les frameworks de nombreux langages de programmation offrent cette fonction. Supprimer les caractères spéciaux de la saisie laisse facilement des failles, et les contrôles de saisie côté navigateur peuvent être contournés par les attaquants ; aucune de ces deux mesures ne suffit à elle seule.

Mesures qui limitent les dégâts

En plus de la contre-mesure fondamentale, on ajoute d'autres couches : n'accorder au compte que l'application utilise pour se connecter à la base de données que les privilèges minimaux nécessaires (principe du moindre privilège), ne pas afficher de messages d'erreur détaillés aux utilisateurs, et détecter les chaînes d'attaque typiques avec un WAF (pare-feu applicatif web). Un WAF n'est qu'une aide et ne remplace pas la correction de l'application.

S'entraîner : questions sur Injection SQL

Comme contre-mesure à l'injection SQL, pourquoi les requêtes préparées avec paramètres substituables (requêtes paramétrées) sont-elles considérées comme plus fondamentales que la suppression des caractères dangereux de la saisie ?

  1. AParce que la saisie est chiffrée avant d'être transmise à la base de données, si bien que les attaquants ne peuvent pas la lire
  2. BParce que le navigateur vérifie les types de caractères saisis, si bien que les chaînes malveillantes n'atteignent jamais le serveur
  3. CParce que la structure de l'instruction SQL est fixée d'abord et que la saisie n'est transmise ensuite que comme valeurs ; quels que soient les caractères qu'elle contient, elle n'est jamais interprétée comme une partie de la commande
Afficher la réponse et l'explication

Réponse : C. Parce que la structure de l'instruction SQL est fixée d'abord et que la saisie n'est transmise ensuite que comme valeurs ; quels que soient les caractères qu'elle contient, elle n'est jamais interprétée comme une partie de la commande

Avec une requête préparée, une instruction SQL dont les valeurs sont remplacées par des symboles (paramètres substituables), comme « SELECT … WHERE id = ? AND password = ? », est d'abord transmise à la base de données pour en fixer la structure, puis la saisie y est rattachée uniquement en tant que valeurs (liaison, ou binding). La saisie est traitée comme une donnée du début à la fin ; même si elle contient des apostrophes, elle ne devient jamais une partie d'une commande, par exemple d'une commande qui ajoute une condition. Supprimer ou échapper les caractères dangereux exige de traiter sans omission toutes les règles détaillées propres à chaque type de base de données et à chaque codage des caractères, et une seule faille suffit à faire réussir l'attaque. Les contrôles de saisie dans le navigateur peuvent être contournés si l'attaquant envoie directement des requêtes sans passer par un navigateur ; ils servent la commodité et ne constituent pas une mesure de sécurité. En outre, donner au compte qui se connecte à la base de données les privilèges minimaux permet de limiter les dégâts.

Questions fréquentes

Peut-on empêcher l'injection SQL par l'échappement ?

L'échappement peut l'empêcher dans certains cas, mais il faut traiter sans omission toutes les règles propres à chaque type de base de données et à chaque codage des caractères, et une seule faille suffit à faire réussir l'attaque. Les requêtes préparées avec paramètres substituables sont donc la contre-mesure de base.

Peut-on empêcher l'injection SQL en limitant la longueur des saisies ?

Non. Même des chaînes courtes peuvent changer le sens d'une commande. Les limites de longueur ou de types de caractères sont des mesures complémentaires ; la contre-mesure fondamentale reste les requêtes préparées.

« Injection SQL » dans les explications

Questions mentionnant « Injection SQL » (3)

  1. Comme contre-mesure à l'injection SQL, pourquoi les requêtes préparées avec paramètres substituables (requêtes paramétrées) sont-elles considérées comme plus fondamentales que la suppression des caractères dangereux de la saisie ?
  2. Lequel des exemples suivants relève de l'ingénierie sociale ?
  3. Dans une application web, saisir une chaîne comme ' OR '1'='1 dans le champ du mot de passe de l'écran de connexion permet de se connecter sans connaître le mot de passe. Comment s'appelle cette attaque ?

Termes associés

SQL Ingénierie sociale (social engineering) Hameçonnage (phishing) Attaque zero-day (attaque du jour zéro) Authentification multifacteur (MFA) Code d'authentification de message Cross-site scripting (XSS) Cryptographie à clé publique (cryptographie asymétrique) Cryptographie symétrique (cryptographie à clé secrète) Fonction de hachage

Retour au glossaire