Analysis, hypothesis, and successful use of a small BUG

Guidance: note that the last prompt is from my point of view. This is a Bug (although it cannot be used, it is worth noting). I found this Bug when testing the SystemDev news system, because it is useless and hypothetical, it is separated from the article SystemDev news system vulnerability analysis (skip this article ).

　　Small Bug Analysis

Let's take a look at part of the background verification file session. asp code.

AdminUID = session ("AdminUID ")

AdminPWD = session ("AdminPWD ")

Set rs = server. CreateObject ("ADODB. RecordSet ")

Rs. Source = "select id from Admin where AdminUID =" & AdminUID & "and AdminPWD =" & AdminPWD &""

Rs. Open rs. Source, conn, 1, 1

This Code uses sessions to verify AdminUID and AdminPWD, and stores them in the corresponding variables. Then, both variables are involved in the SQL query (where AdminUID and AdminPWD use AdminUID = trim (Request. form ("AdminUID") and AdminPWD = trim (Request. form ("AdminPWD ). Most of the files include session. asp files. From here, the program looks safe.

Next, let's take a look at the two files: ChangPassword1.asp and ChangPassword2_submit.asp, which are used by the Administrator to change the password. Neither of these two files has the include session. asp file, and ChangPassword1.asp does not have any permission to judge the statement (this should be dangerous ). Of course, this file does not pose any threat. In ChangPassword2_submit.asp, we can see the following code: "UserName = session (" AdminUID ")". You may think this sentence is useless. Otherwise, the purpose of this Code is to save the AdminUID session in the UserName variable. The following code may be written as follows:

If UserName = "" then Response. Write "Logon timeout. Please log on again! " Response. End

However, the author did not make a session judgment, but directly wrote the following code.

　　

OldPassword = trim (Request. Form ("OldPassword ")) NewPassword = trim (Request. Form ("NewPassword ")) NewPassword2 = trim (Request. Form ("NewPassword2 ")) ...... Omitted ...... Set rs = server. CreateObject ("ADODB. RecordSet ") Rs. Source = "select id from Admin where AdminPWD =" & OldPassword &"" Rs. Open rs. Source, conn, 1, 1 If not rs. EOF then SQL = "update Admin set AdminPWD =" & NewPassword & "where AdminUID =" & UserName &"" Conn.exe cute (SQL) Session ("AdminPWD") = NewPassword

It directly accepts the data transmitted from the first file, stores it in three password variables, and then executes the SQL query. In SQL query, "SQL =" update Admin set AdminPWD = "& NewPassword &" where AdminUID = "& UserName &" adds the variable that saves the session value to the UserName query. I don't know if the author is lucky or I really want to make this decision. The result is that we cannot directly change the administrator password. Why? Because the session is saved in UserName! Our sessions are not stored on the server, so even if we modify the password, it is impossible to change the administrator password. We can see from the code that we can inject in the password modification, but it does not threaten the system. Here we will introduce it first, because it will be used below, as shown in interface 1 of ChangPassword1.asp.

Figure 1

Although the server does not save our Session, you can refer to the following code:

Set rs = server. CreateObject ("ADODB. RecordSet ") Rs. Source = "select id from Admin where AdminPWD =" & OldPassword &"" Rs. Open rs. Source, conn, 1, 1