PHP Security-SQL injection

SQL injection is one of the most common vulnerabilities in PHP applications. In fact, it is surprising that a developer must make two mistakes at the same time to cause an SQL injection vulnerability. One is that the developer does not filter the input data (...

SQL injection

SQL injection is one of the most common vulnerabilities in PHP applications. In fact, it is surprising that a developer must make two mistakes at the same time to cause an SQL injection vulnerability. One is that the developer does not filter the input data (filter the input ), another is that the data sent to the database is not escaped (escape output ). These two important steps are indispensable and need special attention at the same time to reduce program errors.

For attackers, it is necessary to think about and test SQL injection attacks and make rational reasoning on the database solution (assuming that the attacker cannot see your source program and database solution ), consider the following simple logon form:

CODE:

Figure 3-1 shows the form in the browser.

As an attacker, he starts to speculate on the query statement used to verify the user name and password. By viewing the source file, you can start to guess your habits.

Figure 3-1. display the logon form in the browser

Naming conventions. It is usually assumed that the field name in your form is the same as the field name in the data table. Of course, ensuring that they are different may not be a reliable security measure.

The first prediction generally uses the query in the following example:

CODE:

Using the MD5 value of the user password is a common practice, but it is not particularly safe now. Recent research shows that the MD5 algorithm is flawed, and a large number of MD5 databases reduce the difficulty of MD5 reverse cracking. Visit # to view the demo.

In the original article, Wang Xiaoyun, a professor at Shandong University, showed that the MD5 "collision" can be quickly found, that is, two different files and strings with the same MD5 value can be generated. MD5 is an information digest algorithm, rather than an encryption algorithm. reverse cracking is impossible. However, in the preceding special case, using md5 directly is dangerous.

The best protection method is to append a custom string to the password, for example:

CODE:

Of course, attackers may not be able to guess for the first time. They often need to perform some tests. A better test method is to input single quotes as user names, because this may expose some important information. Many developers call the mysql_error () function to report errors when an error occurs in Mysql statement execution. See the following example:

CODE:

Although this method is useful in development, it can expose important information to attackers. If the attacker uses single quotes as the user name and mypass as the password, the query statement will become:

CODE:

After the statement is sent to MySQL, the system displays the following error message:

You have an error in your SQL syntax. Check themanual that corresponds to yourMySQL server version for the right syntax to usenear 'WHERE username = ''' ANDpassword = 'a029d0df84eb55

The attacker knows the two field names (username and password) and the order in which they appear in the query. In addition, attackers also know that the data is not properly filtered (the program does not prompt illegal user names) and escaped (database errors occur), and the format of the WHERE condition is also exposed, attackers can then try to manipulate records that match the query.

At this point, attackers have many options. First, try to enter a special user name to make the query match regardless of whether the user name and password match:

myuser' or 'foo' = 'foo' --

Assuming that mypass is used as the password, the entire query will become:

CODE:

The query statement is interrupted because an SQL comment mark is inserted in the middle. This allows an attacker to log on without knowing any valid user name or password.

If a valid user name is known, attackers can log on as the user (such as chris:

Chris '--

Attackers can control this account as long as chris is a valid user name. The reason is that the query changes to the following:

CODE:

Fortunately, SQL injection is easy to avoid. As mentioned in chapter 1, you must always filter input and escape output.

Although neither step can be omitted, most SQL Injection risks can be eliminated as long as one of them is implemented. If you only filter the input without escaping the output, you may encounter a database error (legal data may also affect the correct format of the SQL query), but this is also not reliable, legal data may also change the behavior of SQL statements. On the other hand, if you escape the output without filtering the input, you can ensure that the data does not affect the SQL statement format, and also prevent a variety of common SQL injection attacks.

Of course, you still need to follow these two steps at the same time. The method for filtering input depends entirely on the type of input data (see the example in chapter 1), but escape is used to send the output data to the database as long as the same function is used. For MySQL users, you can use the mysql_real_escape_string () function ():

CODE:

Try to use the escape functions designed for your database. If not, using the addslashes () function is the final better method.

When all data used to create an SQL statement is properly filtered and escaped, the risk of SQL injection is actually avoided.

CODE:

If you are using a database operation class that supports parameterized query statements and placeholders (such as PEAR: DB and PDO), you will get another protection. See the following example of using PEAR: DB:

CODE:

 query($sql,array($clean['last_name']));?>

CODE:

As the data in the preceding example cannot directly affect the format of the query statement, the risk of SQL injection is reduced. PEAR: The DB will automatically escape according to your database requirements, so you only need to filter the output.

If you are using a parameterized query statement, the input content will only be processed as data. In this way, there is no need to escape, although you may think this is a necessary step (if you want to stick to the escape output habit ). In fact, whether to escape is basically not affected, because there is no special character to be converted. To prevent SQL injection, parameterized query statements provide powerful protection for your program.

Note: Most virtual hosts now enable the magic_quotes_gpc option for SQL injection. in this case, all client GET and POST data are automatically processed by addslashes, therefore, SQL injection of string values is not feasible, but SQL injection of numeric values should be prevented, such as processing using functions such as intval. However, if you write generic software, you need to read magic_quotes_gpc from the server and then process it accordingly.

The above is the content of PHP Security-SQL injection. For more information, see PHP Chinese website (www.php1.cn )!