Comment fonctionne l'injection SQL via URL?
Je me demande comment l'injection SQL fonctionne via URL avec SQL dans le paramètre. Supposons que j'ai une base de données avec une table nommée mytable. Lorsque j'obtiens un ID de la méthode POST je le mets dans cette requête:
SELECT * FROM `mytable` WHERE id='POST[id]'
Même si l'utilisateur met du SQL comme:
SELECT * FROM 'mytable'
C'est devenu quelque chose comme ça:
SELECT * FROM `mytable` WHERE id='SELECT * FROM 'mytable'
Il revient donc simplement:
Vous avez une erreur dans votre syntaxe SQL.
Alors, comment fonctionne ce type d'attaque? Comment l'attaquant peut-il modifier la requête sans provoquer d'erreur de syntaxe?
Le point d'injection SQL est de modifier la requête où se trouve la variable.
Prenons l'exemple de la requête que vous avez écrite. Si la variable id contient quelque chose comme ça et n'est pas correctement filtrée:
' OR 1=1#
Il retournerait chaque ligne car il a été modifié comme suit:
SELECT * FROM `mytable` WHERE id='' OR 1=1#'
L'astuce pour éviter l'erreur de syntaxe consiste à commenter le reste de la requête (le caractère # le fait dans cette situation.
L'exploitation des injections SQL est l'art de fournir des paramètres qui, lorsqu'ils sont incorporés dans une instruction SQL, aboutissent à une syntaxe d'instruction SQL valide tout en changeant la sémantique voulue par le développeur en une valeur rentable pour un attaquant.
Selon le DMBS et le type d'instruction, dans lequel l'injection est possible, les résultats d'une injection SQL réussie varient de la divulgation d'informations (lecture de données arbitraires, fichiers locaux) à la manipulation de données (insertion, suppression ou modification de données arbitraires, écriture fichiers locaux), jusqu'à l'exécution arbitraire de commandes.
Le SGBD et l'instruction affectent également les techniques qui peuvent être utilisées pendant l'exploitation. Si l'API de connexion ne permet pas l'exécution de plusieurs instructions (appelées "requêtes empilées"), le souvent cité Robert';DROP TABLE Students; -- n'aurait aucun effet. Dans ce cas, vous seriez également limité aux effets secondaires du type d'instruction particulier dans lequel l'injection se produit : S'il s'agit d'une instruction SELECT, il est très probable que seule la lecture des données soit possible, mais ne pas écrire ou supprimer des données.
Et enfin, cela dépend aussi de la rétroaction donnée à l'attaquant sur le résultat de l'instruction exécutée. Les messages d'erreur, en particulier ceux générés par une API de connexion ou un langage de programmation, sont souvent assez techniques et verbeux et peuvent révéler des informations critiques, par exemple, des parties de l'instruction ayant échoué comme "Vous avez une erreur dans votre syntaxe SQL près de '…'". Ces messages peuvent fournir aux attaquants des informations pratiques sur le contexte dans lequel l'injection se produit (type d'instruction, type de clause, niveau d'imbrication des parenthèses, etc.).
Dans votre exemple, un simple id=' OR '1'='1 entraînerait la déclaration suivante:
SELECT * FROM `mytable` WHERE id='' OR '1'='1'
Avec cette dernière expression '1'='1' toutes les lignes seront sélectionnées. Une extension serait d'utiliser une sous-requête pour lire des données arbitraires de manière aveugle:
SELECT * FROM `mytable` WHERE id='' OR EXISTS (SELECT * FROM users WHERE name='admin' AND password LIKE 'a%') AND '1'='1'
Ici, toutes les lignes ne seraient sélectionnées que s'il existe un utilisateur admin dont le mot de passe commence par a, sinon aucune ligne ne serait sélectionnée. Cette technique est appelée "store à base booléenne".