En tant qu’instruction de requête standard internationale pour une base de données, les instructions SQL ont été largement utilisées dans divers environnements de programmation. En tant que système mature et stable, la vérification de la connexion et des mots de passe des utilisateurs est essentielle. Dans mon travail quotidien de programmation, j’ai constaté que de nombreux programmeurs utilisent des instructions SQL pour vérifier les mots de passe des utilisateurs via une déclaration comme celle-ci :
sql="Select * depuis la table utilisateur où nom='"+nom+"' et mot de passe='"+mot de passe+"' »
Le nom et le mot de passe correspondent aux noms d’utilisateur et mots de passe entrés par l’utilisateur, et les instructions ci-dessus sont exécutées pour vérifier si l’utilisateur et le mot de passe sont légitimes et valides. Cependant, grâce à l’analyse, on peut constater qu’il existe des failles fatales dans les affirmations ci-dessus. Lorsque nous entrons la chaîne suivante dans le nom d’utilisateur : 111'or'1=1, puis que nous saisissons le mot de passe de manière décontractée, nous le définissons sur aaaa. Après le remplacement de la variable, l’instruction SQL devient la chaîne suivante :
sql="Select * à partir de la table utilisateur où nom='111'or'1=1' et mot de passe='aaaa'
Nous savons tous que lorsque l’instruction select juge les conditions de requête, elle ignore les opérations suivantes et (et) lors de la rencontre d’opérations ou (ou) opérations, et la valeur de 1=1 dans l’instruction ci-dessus est toujours vraie, ce qui signifie que peu importe la valeur saisie dans le mot de passe, elle peut passer la vérification du mot de passe ci-dessus ! La solution à ce problème est très simple, et il existe de nombreuses méthodes, la plus couramment utilisée étant de juger la légitimité de l’utilisateur et du mot de passe saisi avant d’effectuer la vérification, et les caractères spéciaux tels que des guillemets simples ou des signes égals ne sont pas autorisés.
Les problèmes ci-dessus, bien qu’ils puissent sembler simples, existent. Par exemple, la version précoce du célèbre jeu en ligne « Smiling Proud Jianghu » sur Internet avait un tel problème, et l’auteur a également analysé avec soin certains des programmes qu’il avait écrits auparavant après avoir lu le rapport de vulnérabilité concernant ce jeu, et il y avait de nombreuses failles de ce type. Ça devrait vraiment attirer notre attention. Cela met également en lumière le manque d’expérience en programmation et de sensibilisation à la sécurité des jeunes programmeurs, y compris l’auteur. En même temps, cela nous rappelle aussi que les programmeurs doivent prendre pleinement en compte la sécurité du programme lors de leur conception, et ne doivent pas être négligents, et qu’une omission apparemment mineure peut entraîner de graves conséquences.
|
Publié sur 26/11/2014 15:47:51
|
|
|
