Injection SQL avec AND 1 = 1
Veuillez expliquer la signification de "AND 1 = 1 "dans une attaque par injection SQL. Elle provient d'un exercice dans mon université. Par exemple.
select * from user where id = 'smith'' AND 1=1;-- and birthdate = 1970;
ou
select * from user where id = 'smith' and birthdate = 1970 AND 1=1;--;
La question spécifique est l'injection SQL avec ET 1 = 1 et non OU 1 = 1. Il y a une grande différence ici dans ce que l'OP demande. Si j'étais votre professeur et que vous me fournissiez la réponse de Jonathan Mueller, vous obtiendriez une mauvaise note car vous ne comprenez pas la question.
ET 1 = 1 est généralement utilisé dans injections SQL aveugles . C'est quand vous devez déterminer entre un état vrai ou faux à partir du résultat de l'application pour déterminer quel est le résultat réel. Vous n'obtenez pas de données répertoriées dans le résultat, la seule chose renvoyée est un état de changement.
Si vous essayez d'exploiter une injection SQL aveugle avec OR 1 = 1 vous échouerez car l'utilisation principale de OR 1 = 1 est de créer un toujours vrai afin de tirer le maximum de données de la base de données ou de forcer une vraie déclaration dans le cas où un script de connexion est exploité.
Un exemple pratique d'exploitation SQL aveugle:
Nous utilisons notre exemple: http://www.site.com/news.php?id=7 Essayons de le tester: http://www.site.com/news.php ? id = 7 et 1 = 1 <--- c'est toujours vrai et la page se charge normalement, c'est ok.
http://www.site.com/news.php?id=7 et 1 = 2 <--- c'est faux, donc s'il manque du texte, une image ou du contenu sur la page retournée alors ce site est vulnérable à une injection SQL aveugle.
Un autre exemple où vous essayez de comprendre la version de MySQL:
http://www.site.com/news.php?id=7 et substring (@@ version, 1,1) = 4 Ceci devrait retourner TRUE si la version de MySQL est 4. Remplacer 4 avec 5, et si la requête renvoie VRAI, la version est 5.
Exemples tirés de: http://www.exploit-db.com/download_pdf/14475
Normalement, vous verriez la phrase "OU 1 = 1 '". La raison en est que si le programmeur ne gère pas correctement les paramètres (comme l'ID utilisateur), un attaquant pourrait utiliser un OR 1=1 pour renvoyer toutes les données du tableau.
Par exemple, disons que nous voulons obtenir des détails sur un utilisateur nommé smith. La requête pourrait être select * from user where id = '?', où le point d'interrogation est remplacé par un paramètre de l'entrée d'un utilisateur. Si l'attaquant a réussi smith' OR 1=1--, le SQL résultant serait select * from user where id = 'smith' OR 1=1--'. Dans ce cas, le deuxième guillemet simple de la requête d'origine est ignoré car il fait partie d'un commentaire et la requête retournerait toutes les données de la table utilisateur.
Pour donner un exemple (quelque peu trivial, de haut en bas) d'injection SQL, imaginez cette requête quelque part dans le code de votre application ...
select 1 from user where name='[NAME]' and password='[PASS]'
après que Malicious Guy ait défini les paramètres nommés ci-dessus à son choix, vous obtenez:
select 1 from user where name='admin' --' and password='[PASS]'
. .]
Ainsi, en supposant que la requête est censée renvoyer 1 pour succès et un ensemble vide pour un utilisateur ou un passage invalide, un 1 serait renvoyé par erreur, permettant à cet utilisateur malveillant de se connecter en tant que compte "admin".