Récemment, je suis tombé sur une feuille de triche SQL Injection qui contient cette feuille de triche particulière que je suis confus par ' or 1=1/*
En supposant que je le teste sur ce code côté serveur ci-dessous.
SELECT * FROM users WHERE login='$login' AND password='$password';
Eh bien, je n'arrive pas à le contourner avec cette feuille de triche. Je suis juste curieux de savoir pourquoi ils l'incluent à la place comme une feuille de triche? Comment cette feuille de triche particulière est-elle utilisée?
Ce que je suppose et utilise ma logique, c'est que cette utilisation de la feuille de triche est possible uniquement lorsque le programmeur a placé par erreur la balise de commentaire de fin * / derrière la requête SQL, comme indiqué dans le code côté serveur ci-dessous .
SELECT * FROM users WHERE login='' or 1=1/*' AND password='$password' */;
N'hésitez pas à expliquer l'utilisation et à vérifier plutôt ma propre compréhension de l'utilisation de cette feuille de triche particulière à la place.
Modifié: Pour les malentendus, ce que je voulais dire pour */à la fin du code comme mentionné si un programmeur l'a mis par erreur est montré ci-dessous.
SELECT * FROM users WHERE login='$login' AND password='$password' */;
Il y a quelques considérations ici, la première consiste à expliquer comment cela est censé fonctionner:
Les injections SQL sont un type de hack très ancien qui ne devrait pas affecter les implémentations SQL modernes. Avant de pouvoir utiliser des instructions préparées, les requêtes SQL étaient normalement effectuées à l'aide de chaînes concaténées. Cela signifiait que quelle que soit votre entrée ferait partie du sql exécuté comme ceci:
$login = "John";
$password = "' OR 1=1 --";
$myIP = '555.555.555.555';
$sql = "SELECT * FROM users WHERE login='" . $login . "' AND password='" . $password . "' AND userip = '" . $myIP . "'";
echo $sql;
SORTIE: SÉLECTIONNEZ * DES UTILISATEURS O users login = 'John' ET mot de passe = '' OR 1 = 1 - ET userip = '555.555.555.555'
Ce premier 'fermera la citation de chaîne pour garder la syntaxe valide. Puis, comme 1 est toujours égal à 1, vous créez une instruction select qui est toujours vraie. Cela signifie que vous sélectionnerez l'utilisateur "John" vous permettant de vous connecter en tant que lui sans connaître son mot de passe. Ensuite - est la syntaxe SQL pour remarquer tout ce qui vient après. Ceci est utilisé pour éliminer toute autre condition qui pourrait empêcher votre connexion réussie, telle que la validation IP ou quelque chose de cette nature.
La deuxième chose ici est le/*. Cela interrompra en fait une injection 1 = 1 car il s'agit d'une syntaxe SQL de transaction non valide. Cela dit,/* peut être utilisé dans une attaque au niveau de l'exécution. De nombreux développeurs font trop confiance aux déclarations préparées. Ce n'est pas parce qu'il n'exécute pas d'entrée lors de la transaction SQL qu'il ne peut pas contenir de choses qui peuvent être exécutées plus tard.
Par exemple, si vous avez une zone de saisie sur un site Web et que vous souhaitez tester pour voir si le site est vulnérable aux attaques JS-XSS, vous pouvez saisir "<script>/*". Cela signifie que lorsque votre programme va prendre cela de votre base de données et l'exécuter, vous exécuterez un JavaScript qui remarque le reste de votre page, puis il tuera votre programme lorsque vous essayez de charger la sortie de ces informations.
En bref, votre source mélange la syntaxe de remarquage pour 2 types d'attaques différents, mais ce sont deux préoccupations légitimes étant donné les bonnes vulnérabilités.