As an international standard database query statement, SQL statements have been widely used in various programming environments. As a mature and stable system, user login and password verification are essential. In my daily programming work, I found that many programmers use SQL statements to verify user passwords through a statement like this:
sql="Select * from user table where name='"+name+"' and password='"+password+"'"
The name and password are the usernames and passwords entered by the user, and the above statements are executed to verify whether the user and password are legitimate and valid. However, through analysis, it can be found that there are fatal loopholes in the above statements. When we enter the following string in the user name: 111'or'1=1, then enter the password casually, we set it to aaaa. After the variable is replaced, the SQL statement becomes the following string:
sql="Select * from user table where name='111'or'1=1' and password='aaaa'
We all know that when the select statement judges the query conditions, it will ignore the following and (and) operations when encountering or (or) operations, and the value of 1=1 in the above statement is always true, which means that no matter what value is entered in the password, it can pass the above password verification! The solution to this problem is very simple, and there are many methods, the most commonly used is to judge the legitimacy of the user and password entered by the user before performing verification, and special characters such as single quotation marks and equal signs are not allowed.
The above problems, although they may seem simple, do exist. For example, the early version of the famous online game "Smiling Proud Jianghu" on the Internet had such a problem, and the author also carefully analyzed some of the programs he had written before after reading the vulnerability report about this game, and there were many such loopholes. This really should be our attention. This also exposes the lack of programming experience and security awareness of young programmers, including the author. At the same time, it also reminds us that programmers should fully consider the security of the program when designing the program, and should not be sloppy, and a seemingly small omission may cause serious consequences.
|
Posted on 11/26/2014 3:47:51 PM
|
|
|
