Today's web-based attacks are generally injection. The reason for injection is generally incomplete filtering of variables, which allows intruders to illegally execute programs or query and modify arbitrary data. As injection attacks become more and more intense, some specialized filtering codes have emerged. However, imperfections in some filtering codes may lead to new attacks. The following uses the most widely used filtering code - SQL universal anti-injection program - to explain the causes, utilization methods and preventive measures of the vulnerability.
SQL universal anti-injection program is written by Feng Zhiqiu of Firefox. It is a fairly complete anti-injection code. It can implement get submission filtering for the defined filter characters, and can record the data information submitted by the attacker's IP. When using it, you only need to add the code <--#Include File="WrSky_Sql.Asp"--> to the header of the file to prevent injection to achieve filtering of variables. If you add program code after the database connection file (such as conn.asp), you can achieve variable filtering of the entire site, thereby achieving the anti-injection effect.
Okay, let's look at the code of the variable filtering part first:
'--------Definition part------------------
Dim Fy_Post,Fy_Get,Fy_In,Fy_Inf,Fy_Xh,Fy_db,Fy_dbstr
'Customize the strings that need to be filtered, separated by "maple"
Fy_In = "' maple; maple and maple exec maple insert maple select maple delete maple update maple count maple * maple% maple chr maple mid maple master maple truncate maple char maple declare"
'----------------------------------
%>
＜
Fy_Inf = split(Fy_In,"Maple")
'--------POST part------------------
If Request.Form＜＞Then
For Each Fy_Post In Request.Form
For Fy_Xh=0 To Ubound(Fy_Inf)
If Instr(LCase(Request.Form(Fy_Post)),Fy_Inf(Fy_Xh))＜＞Then
'--------GET part------------------
If Request.QueryString＜＞Then
For Each Fy_Get In Request.QueryString
For Fy_Xh=0 To Ubound(Fy_Inf)
If Instr(LCase(Request.QueryString(Fy_Get)),Fy_Inf(Fy_Xh))＜＞Then
this code defines the filtering of commonly injected variables such as "'", "and", etc. If you feel that the filtering is not enough or too much, you can do it by yourself Add or subtract characters. Obviously, as long as the data submitted to the server through get or post contains filtered characters, it will be prohibited by the program. This leads to a problem. If you add program code after the forum's database connection file, as long as the content of the post contains filtered characters, it will be banned. According to the default filtering content, it seems that it is almost impossible to post if the content is in English. In addition, some special characters (such as the percent sign "%") are sometimes used when defining the forum style. If these special characters are filtered, the entire forum will not function properly. Regarding the above-mentioned problem, I used dvbbs to test it, and the result was exactly what I expected.
The way to solve the above problem is to prevent injection of connection statements only in the files that need to be filtered. But this workload is relatively large, and generally webmasters don’t know what files need to be filtered. Therefore, my suggestion is to add the filtering code to conn.asp, then create a connl.asp that does not contain the filtering code, and connect the files that definitely do not need filtering and the filtering code has an impact on the operation of this file to conn1.asp, but you need to Note that the basic contents of the two data connection files must be consistent. In addition, it is best not to use filtered characters in style settings. If you really need to use them, you can delete the filtering of these characters in the anti-injection program.
The above is about the impact of the anti-injection program on the operation of the site, and it cannot cause any harm. In fact, the real harm comes from the data recording part. Let's take a look at this part of the code:
''--------Write to the database-------Header--------
Fy_dbstr="DBQ="+server.mappath("SqlIn.mdb")+";DefaultDir=;DRIVER={Microsoft Access Driver (*.mdb)};"
Set Fy_db=Server.CreateObject("ADODB.CONNECTION")
Fy_db.open Fy_dbstr
Fy_db.Execute("insert into SqlIn(Sqlin_IP,SqlIn_Web,SqlIn_FS,SqlIn_CS,SqlIn_SJ) values('"&Request.ServerVariables("REMOTE_ADDR")&"','"&Request.ServerVariables("URL")&"',' GET','"&Fy_Get&"','"&replace(Request.QueryString(Fy_Get),"'","''")&"')")
Fy_db.close
Set Fy_db = Nothing
'--------Write to database-------Tail--------
Response.Write "＜Script Language=JavaScript＞alert('Fengwang SQL universal anti-injection system prompt↓ nnPlease do not try to inject illegal characters in the parameters nnHTTP://WwW.WrSkY.CoM System version: V2.0 (ASP) perfect version');＜Script＞
Response.Write "Illegal operation! The system made the following records↓＜br＞"
Response.Write "Operation IP:"&Request.ServerVariables("REMOTE_ADDR")&"<br>"
Response.Write "Operation time:"&Now&"<br>
response.Write "Operation page:"&Request.ServerVariables("URL")&"<br>"
Response.Write "Submission method: GET＜br＞"
Response.Write "Submit parameters:"&Fy_Get&"<br>"
Response.Write "Submit data:"&Request.QueryString(Fy_Get)
Response.End
End If
Next
Next
End If
'----------------------------------
The function of this code is to record the attacker's information and actions. so that we can take necessary countermeasures. It can be seen from the code that the program records the attacker's IP, submission address, submission content, etc., but there are obviously several loopholes here:
1. Frequent attacks are not processed. In other words, no matter how we submit legal data, it will be recorded by the program, which will most likely lead to malicious DOS attacks. I did an experiment on this. I submit the following statement after the URL of a protected file: and (select top l asc(mid (username,l,l)) from admin)>0, use the key wizard to record the submission process, and then automatically repeat the submission . After a while, the database size changed significantly (as shown in Figures 1 and 2). As you can imagine, if you use tools such as Shuoxue to enable multi-thread submission, DOS will definitely not be a problem.
Figure 1
Figure 2
2. The record data length is not truncated. This is what I discovered during my testing of anti-injection programs affecting forum operations. As shown in Figure 3, if the post content contains filtered characters, the post content will be completely recorded in the database. General forums or article systems have limits on the length of published articles, but the SQL universal anti-injection program does not impose any restrictions on this. If an attacker submits an overly long content after the URL of the protected file, it is likely to cause the program to crash. Because the harm is relatively high, I did not test it, but the content I submitted up to 100K was recorded as usual.
Figure 3
3. Data content conversion and database explosion problem. Judging from the code, the program records the illegally submitted data directly into the database without conversion. In other words, no matter what you submit, as long as it contains filtered content, the program will record all the content you submit. This problem is not serious originally, but for the sake of "security", some webmasters like to change all mdb files to asp suffix. In addition, there is only one table in the database of the anti-injection program, so we can obtain the webshell by directly writing the protected file URL to the database. During the test process, we changed sqlin.mdb to sqlin.asp, and then added After the URL of the protected file was entered, a Binglangzi micro ASP backdoor was entered. After connecting with the Ice Fox client, wedshll was successfully obtained.
Because this method of obtaining webshell requires making sure that the other party's database is running in ASP format and knows the data path, we must find a way to get the path of this database. Under normal circumstances, we can directly guess the database path, but in fact this path can be exposed. Looking at the entire anti-injection program, we have not found any explosion-proof library statements, so we only need to directly access or use the %5C method. The database is exposed. If the program code is placed directly after the database connection file, since the data connection file generally contains explosion-proof statements, we cannot expose the address of the database.
The above mentioned are all problems in the data recording process. Competent webmasters can fix the relevant loopholes by themselves, such as automatically blocking IPs for large amounts of repeated submissions of data. In fact, we can completely remove the data recording part of the code, which will not affect the filtering of variables, and even if the attacker's information is recorded, it will not be very useful. So I suggest that it is best to remove this code, so that all vulnerabilities will no longer exist.
Okay, that’s it for this article. Finally, I would like to remind you that when using security protection programs, you should also pay attention to the security issues of the program itself.
Special reminder: Anti-injection program 3.0 also has loopholes, and the loopholes are more serious.