Fully block SQL injection attacks in PHP

I. Type of injection type of attack

There may be many different types of attack motives, but at first glance there seems to be more types. This is very real-if a malicious user discovers a way to execute multiple queries.

If your script is executing a SELECT command, an attacker can force the display of every row in a table-by injecting a condition such as "1=1" into the WHERE clause, as follows (where the injection portion is shown in bold):

SELECT * FROM wines WHERE variety = ' Lagrein ' OR 1=1; '

As we discussed earlier, this may be useful information in itself because it reveals the general structure of the table (which is not achievable by a common record) and potentially displays records that contain confidential information.

An update directive potentially has a more immediate threat. By placing other attributes in the SET clause, an attacker can modify any field in the currently updated record, such as the following example (where the injection portion is shown in bold):

UPDATE Wines SET type= ' red ', ' vintage ' = ' 9999 ' WHERE variety = ' Lagrein '

By adding a constant real condition such as 1=1 to a WHERE clause of an update instruction, the scope of the modification can be extended to each record, such as the following example (where the injection portion is shown in bold):

UPDATE Wines SET type= ' red ', ' vintage ' = ' 9999 WHERE variety = ' lagrein ' or 1=1; '

The most dangerous instruction may be delete-it is not difficult to imagine. The injection technology is the same as we have seen-by modifying the WHERE clause to extend the scope of the affected record, such as the following example (where the injection portion is shown in bold):

DELETE from wines WHERE variety = ' Lagrein ' OR 1=1; '

Second, multiple query injection

Multiple query injection will exacerbate potential damage that an attacker could cause-by allowing multiple destructive instructions to be included in a query. When using the MySQL database, an attacker could easily do this by inserting an unexpected terminator into the query-at which point a injected quotation mark (either single or double quotes) marks the end of the desired variable, and then terminates the instruction with a semicolon. Now, an additional attack instruction may be added to the end of the original instruction that is now terminated. The final destructive query might look like this:

SELECT * FROM wines WHERE variety = ' Lagrein '; GRANT all on *.* to ' badguy@% ' identified by ' gotcha ';

This injection creates a new user Badguy and gives its network privileges (all privileges on all tables), and an "ominous" password is added to this simple SELECT statement. If you follow our recommendations in previous articles-strictly restricting the privileges of users of the process, this should not work because the Web server daemon no longer has the grant privileges you have withdrawn. In theory, however, such an attack could give badguy free authority to implement whatever he does to your database.

As to whether such a multiple query will be handled by the MySQL server, the conclusion is not unique. Some of these may be due to different versions of MySQL, but most of them are due to the way multiple queries exist. The MySQL monitor completely allows such a query. The common MySQL gui-phpmyadmin will copy all of the previous content before the final query and do just that.

However, most of the multiple queries in an injection context are managed by PHP's MySQL extensions. Fortunately, by default, it is not allowed to execute multiple instructions in a single query; Attempting to execute two directives (such as the one shown above) will simply result in failure-no errors are set and no output information is generated. In this case, although PHP is just "behaving" to its default behavior, it does protect you from most simple injection attacks.

The new mysqli extension (reference http://php.net/mysqli) in PHP5, like MySQL, inherently does not support multiple queries, but provides a mysqli_multi_query () function to support you in implementing multiple queries-if you really want to.

However, the situation is more frightening for sqlite-and PHP5-bound SQL database engines (reference http://sqlite.org/and http://php.net/sqlite), which attracts a lot of users ' attention because of their ease of use. In some cases, SQLite allows such a many-to-many query by default, because the database can optimize batch queries, especially very efficient batch INSERT statement processing. However, if the results of the query are used by your script (for example, when retrieving records with a SELECT statement), the Sqlite_query () function will not allow multiple queries to execute.

Third, Invision Power BOARD SQL Injection Vulnerability

Invision Power Board is a well-known forum system. May 6, 2005, a SQL injection vulnerability was found in the login code. The discovery is James Bercegay of Gulftech Security.

This login query looks like this:

$DB->query ("select * from Ibf_members WHERE id= $mid and password= ' $pid '");

Where the member ID variable $mid and the password ID variable $pid are retrieved from the My_cookie () function using the following two lines of code:

$mid = Intval ($std->my_getcookie (' member_id ')); $pid = $std->my_getcookie (' Pass_hash ');

Here, the My_cookie () function retrieves the required variables from the cookie using the following statement:

Return UrlDecode ($_cookie[$ibforums->vars[' cookie_id ']. $name]);

"Note" The value returned from this cookie is not processed at all. Although $mid is coerced into an integer before it is used in a query, $pid remains unchanged. Therefore, it is very easy to suffer from the type of injection we discussed earlier.

Thus, by modifying the My_cookie () function in the following way, this vulnerability is exposed:

if (! In_array ($name, Array (' Topicsread ', ' forum_read ', ' collapseprefs '))

{

return $this->

Clean_value (UrlDecode ($_cookie[$ibforums->vars[' cookie_id ']. $name]));

}

Else

{

Return UrlDecode ($_cookie[$ibforums->vars[' cookie_id ']. $name]);

}

After such corrections, the key variables are returned after the "pass" global Clean_value () function, while the other variables are not checked.

Now that we've got a rough idea of what SQL injection is, how it's injected, and how vulnerable it is, let's explore how to prevent it effectively. Fortunately, PHP provides us with a wealth of resources, so we have sufficient confidence to predict that an application built carefully and thoroughly using the technology we recommend will fundamentally eliminate any possibility of SQL injection from your script-by "cleaning up" your users ' data before it can cause any damage.