Search and fix SQL Injection Vulnerabilities

Search and fix SQL Injection Vulnerabilities
When we want to test a site, the injection tool on the shelf is usually used to blow it up. Although some injection points can be found, it is still a bit blind. My personal opinion is: if the source code is available, start with the source code and find the injection point in the source code. For the source code, some friends may find it difficult. In fact, the source code is not mysterious. It also has certain syntax rules. Watching a set of excellent source code is like watching a beautiful movie, as long as we insist on reading some excellent source code every day, coupled with the guidance of Baidu, it will not take long for you to reveal the secret of the source code. In this case, we will start to look for injection points. There are two targets: Request and SQL statements. Speaking of Request, this is a built-in object in asp program. How? Don't you understand? So let me try it out first! It is used to obtain client information. There are five methods, and there are usually three injection points: 1. Request. QueryString: Get the information submitted by the client. When Form submits information using the Get method or directly submits variable values in the URL, this method is used when the server receives data. 2. Request. Form: it also obtains the information submitted by the client, but it receives the information submitted by Form in the Post method. 3. Request. Cookies: Obtain the Cookies of the client browser. Cookies refer to personal information, such as user names and passwords. In order to reduce errors, some programmers use Request to obtain the information submitted by the client for the first two types of information. This method can be used to obtain the Request. queryString and Request. form, but if the filtering is not good, it will be bitten by the vulnerability. After learning about the Request, enter "request" in "Search" to search. OK! After finding the three Request statements listed above, let's take a look at whether the program filters these Request statements, such as whether the ID value is filtered using INT, for example: id = int (request ("id"); whether to use functions such as replace () or instr () to filter single quotes or special characters. For example: username = replace (request ("username"), "'", ""); or whether the program uses its own filter functions to filter these submitted values. From finding the request parameter to using the submit value in the SQL statement, if there is no layer-1 level in the middle, an injection point will basically appear. When it comes to SQL statements, you cannot mention the following common statements: 1. query statement: Select [(<field name 1> [, <field name 2>,...])] FROM <Table Name JMDCW> [Where <condition expression> [AND | OR <condition expression>...] 2. Update statement: Update <Table Name JMDCW> SET column name 1 = constant expression 1 [, column name 2 = constant expression 2...] where <condition expression> [AND | OR <condition expression>...] 3. Delete statement: Delete FROM <Table Name JMDCW> [Where <condition expression> [AND | OR <condition expression>...] the SQL statement is not introduced here. In the SQL statements listed above, the most frequent occurrence of injection points is the Select statement, and the injection parameters are usually located in the condition after Where. When an unfiltered Request statement enters an SQL statement, it is time to inject it. However, before injecting it, let's take a look at whether this parameter is directly introduced or introduced in single quotes, in addition, whether this parameter is applied to other SQL statements, and then select different processing methods based on different information, or directly crack the statements, or perform UNION queries. Of course, if a program with an injection point uses the SQL database, it will not only obtain some important information, but may even add administrators. The following code uses "ant cinema 3.0" to log out of a user (wantlogin. asp) to introduce a piece of source code: reference in the process, first determine whether the obtained submitted value userid1 is null, if not empty, it will enter the SQL statement, verify that the obtained username and password are consistent with the username and password in the database. If they are inconsistent, the "username and password error" window appears. Otherwise, the "recovery successful" window is displayed. This is also a typical injection vulnerability source code, and the method of receiving is still the request, which provides the greatest convenience for us to submit the injection statement. If we submit the following characters in the URL: http: // 127.0.0.1/wantlogin. asp? Userid1 = aa & pws = bb, because there is no aa user, an error window will pop up. If we replace aa with the following characters: aa 'or 1 = 1 or '1' = '1, pws remain unchanged, so that the statement submitted to the SQL statement becomes the following statement: select money, online from users where userid1 = 'A' or 1 = 1 or '1' = '1' and password = 'md5 (bb )', in the past, we have seen that the test code is generally "or 1 = 1", but here we use one more or. Why do we need one more? In logical operators, the priority of and is higher than or. After the program is run, '1' = '1' and password = 'md5 (bb) 'is first computed )', because the password is casually entered, the password value after and is false, while the '1' = '1' before and is true, but true and false = false, so, the Operation Value of "and" is false. Let's look at the "or" operation. Because the user name does not exist, the value is false. In this way, the logic operation after "where" becomes the following expression: false or true or false, and the result value is true. In this case, the "recovery successful" window is displayed. If you change or 1 = 1 to or 1 = 2, the logical expression is false or false, and the value is false. The pop-up window is "incorrect user name or password. In this way, we can construct some special characters based on the differences in the pop-up window, and then guess the required data, such as querying the administrator ID statement, change 1 = 1 after or to: 1 = (Select top 1 id from admin). Here, admin is used to indicate the name of the Administrator table. If an administrator with ID 1 exists, the "recovery successful" window will pop up. Otherwise, it will prove that the administrator ID is not 1, and other numbers will be used for testing. After you have guessed the administrator ID, change this character segment to the length of the guess Administrator name: 5 <(Select len (adminname) from admin where id = 1), if true, the length is greater than 5. Otherwise, the length is less than or equal to 5. After the length is guessed, use the asc () function to guess the Administrator's name: 90 <(select asc (mid (adminname,) from admin where id = 1). In this loop, the Administrator name and password can be cracked. The Request. queryString and Request. form injection method, while Request. the cookie injection method is implemented by modifying the local Cookies. We recommend that you use some special Cookies modification tools. However, using Cookies for injection causes a lot of trouble, but the principle is the same as the previous injection, so we will not introduce it here. 2. The repair of injection points focuses on how to find the injection points and the simple method of using them. When we know the attack, we will understand how to keep it, although attacking and defending are opposite, they are also mutual. Knowing where there are injection points, it is much easier to fix them again. When looking for injection points, I also mentioned whether the submitted parameters are filtered in the program. Each program filters different injection functions, when patching injection points on our own site, we can refer to the filter functions in other programs, or separately filter some sensitive characters according to our own needs. Here, let's talk about how to fix the injection points. In the preceding SQL statement, userid = '"& request (" userid1 ") &"' is used to introduce submitted parameters in single quotes, the statement is closed with single quotation marks in the submit parameter. In this way, a replace () function is added to filter single quotation marks. The modified statement is as follows: userid = '"& replace (request (" userid1 "),"' "," ") &" ', so that when you submit a character with single quotes, Replace () then, the single quotes are filtered out as null, so that the special characters submitted will lose their meaning. Of course, before userid1 enters the SQL statement, we can determine its length. If it exceeds the specified length, an error will pop up, stop the page and return to the specified page. Of course, some filtering methods in excellent source code can also be used for reference. In short, injection vulnerabilities can be avoided. Even if an injection point occurs, we can easily fix it as long as we analyze the cause!