Directory
- I. Concept of SQL Injection
- Two SQL statements can be injected in two ways.
- Three defense methods
- The first type of query is that the account and password are in an SQL statement. Once they are separated, they will not be injected.
- Method 2: If the password is encrypted by MD5 or other encryption methods, the password will not be complete, so there will be no such error.
- In the third method, we can solve the problem of SQL Injection by passing parameters.
Have we ever wondered whether a database with a large capacity can be easily accessed and deleted as a system. This is SQL injection.
I. Concept of SQL InjectionSQL injection attacks refer to the construction of special input as parameters to pass into Web applications, these inputs are mostly a combination of SQL syntax (some splicing statements used in our billing system). attackers can execute SQL statements to execute the operations they want, the main reason is that the program does not carefully filter user input data, resulting in illegal data intrusion into the system.
2. There are two SQL injection methods:Platform layer injection and code layer injection. The former is caused by insecure database configurations or database platform vulnerabilities. The latter is mainly because the programmer does not carefully filter input, thus, an invalid data query is executed. Based on this, the cause of SQL injection is usually manifested in the following aspects: ① improper type processing; ② insecure database configuration; ③ unreasonable query set processing; ④ improper error handling; ⑤ improper handling of escape characters; ⑥ improper handling of multiple submissions. Now, I will show you the code layer injection:
<SPAN style = "FONT-SIZE: 18px"> txtsql = "select * from user_info where userid = '" & TxtUserName. text & "'and pwd ='" & TxtPassword. text & "'" Set mrc = ExecuteSQL (txtsql, msgtext) If mrc. EOF = False Then MsgBox "SQL injection" End If OK = True mrc. close Unload Me </SPAN> txtsql = "select * from user_info where userid = '" & TxtUserName. text & "'and pwd ='" & TxtPassword. text & "'" Set mrc = ExecuteSQL (txtsql, msgtext) If mrc. EOF = False Then MsgBox "SQL injection" End If OK = True mrc. close Unload Me
This code is actually very simple. When I don't have an account or a password, I use this code to open the database. In this way, if "SQL injection has been made" is displayed ", this means that I am injecting data through the Code layer. At a glance, we can see that my user name is either 1 'or '1' = '1 password. The result is:
It means that your database is dangerous because the user name and password do not exist. This is a simple background Authentication Bypass Vulnerability. The verification bypass vulnerability is the backend Bypass Vulnerability of 'or' = 'or'. It uses the and or calculation rules to cause logical errors in the background scripts. The background query statement is: SQL = 'select admin from user_info where userid = ''' & txtuser. text & ''' & 'and pwd =' & ''' & txtpassword. text & ''', if I use 1 'or '1' = '1 (here, 1 is another number) as the user name and password, then the query becomes: select admin from user_info where userid = '1' or '1' = '1' and pwd = '1' or '1' = '1' according to the calculation rules, there are a total of four query statements, so the query result is false, true, false, or true. Calculate and then calculate or, and the final result is true, so that you can enter the background. This vulnerability must have two fatal conditions. We can start from here for protection.
Iii. Defense methods:First, the account and password are queried in an SQL statement. If they are separated, they will not be injected. SQL = "select * from admin where username = '" & username &' & "passwd = '" & passwd &' If the account and password are queried separately, check the account first, check the password again, so there is no way. When I solve the code like this:
<SPAN style = "FONT-SIZE: 18px"> txtsql = "select * from user_Info where userid = '" & TxtUserName. text & "'" Set mrc = ExecuteSQL (txtsql, msgtext) If mrc. EOF Then MsgBox "does not have this user. Please enter the user name again! ", VbOKOnly + vbExclamation," warning "TxtUserName. setFocus Else If Trim (mrc. fields (1) = Trim (TxtPassword. text) Then OK = True mrc. close Me. hide UserName = Trim (TxtUserName. text) Else MsgBox "Incorrect password. Please try again! ", VbOKOnly + vbExclamation," warning "TxtPassword. setFocus TxtPassword. text = "" End If </SPAN> txtsql = "select * from user_Info where userid = '" & TxtUserName. text & "'" Set mrc = ExecuteSQL (txtsql, msgtext) If mrc. EOF Then MsgBox "does not have this user. Please enter the user name again! ", VbOKOnly + vbExclamation," warning "TxtUserName. setFocus Else If Trim (mrc. fields (1) = Trim (TxtPassword. text) Then OK = True mrc. close Me. hide UserName = Trim (TxtUserName. text) Else MsgBox "Incorrect password. Please try again! ", VbOKOnly + vbExclamation," warning "TxtPassword. SetFocus TxtPassword. Text =" "End If
Method 2: If the password is encrypted, once it is encrypted by MD5 or other encryption methods, the password will not be complete, so there will be no such error. If a field provided by a user is not a strong type, or the type is not enforced, this type of attack will occur. When a numeric field is used in an SQL statement, this attack occurs if the programmer does not check the validity of user input (whether it is a numeric type. For example, statement: = "SELECT * FROM user_info WHERE userid =" & id_text & ";" This statement shows that id_text is a number related to the "userid" field. However, if the terminal selects a string, it bypasses the need for escape characters. For example, if id_text is set to: 1; drop table users, the "users" TABLE is deleted FROM the database, and the SQL statement is changed to: SELECT * FROM User_Info WHERE UserID = 1; drop table users; your database will be irrecoverably deleted. Method 3: We can solve this problem by passing parameters: If you write your own anti-injection code, you usually define a function first, then, write the keywords to be filtered, such as select, "", from, and so on. These keywords are the most commonly used words in query statements. Once filtered, therefore, the data you construct and submit will not be fully involved in database operations.
<SPAN style = "FONT-SIZE: 18px"> Function SafeRequest (ParaName, ParaType) '--- input parameter --- 'paraname: parameter name-parameter type 'paratype: parameter type-numeric type (1 indicates that the preceding parameter is a number and 0 indicates that the preceding parameter is a character) Dim ParaValue = Request (ParaName) If ParaType = 1 then If not isNumeric (ParaValue) then Response. write "parameter" & ParaName & "must be in numeric format! "Response. end End if Else ParaValue = replace (ParaValue, "'", "'' ") End if SafeRequest = ParaValue End function </SPAN> Function SafeRequest (ParaName, ParaType) '--- input parameter --- 'paraname: parameter name-numeric type 'paratype: parameter type-numeric type (1 indicates that the preceding parameter is a number, and 0 indicates that the preceding parameter is a character) dim ParaValueParaValue = Request (ParaName) If ParaType = 1 thenIf not isNumeric (ParaValue) thenResponse. write "parameter" & ParaName & "must be in numeric format! "Response. endEnd ifElseParaValue = replace (ParaValue," '"," ''") End ifSafeRequest = ParaValueEnd function
Of course, there are many SQL injection methods, and I have only written a few. I hope you can give us some advice to protect our database without delay.