Prevent SQL injection implementation code 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. We will discuss this in detail later in this article.
Such as
If your script is executing a SELECT command, then 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:
Copy CodeThe code is as follows:
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-Embedded SQL database engines (reference http://sqlite.org/and Http://php.net/sqlite) bound together with PHP5, 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. Its discovery
James Bercegay, who is 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:
Copy CodeThe code is as follows:
$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:
Copy CodeThe code is as follows:
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.
define each of the values in your query
We recommend that you make sure that you define each of the values in your query. String values are first and foremost, and those that you normally expect should use "single" (Not "double") quotes. On the one hand, if you use double quotes to allow PHP to replace variables within the string, this makes the input query easier; On the other hand, this (admittedly, very small amount) will also reduce the analysis of the PHP code later.
Next, let's use the not-injected query we started with to illustrate this problem:
SELECT * FROM wines WHERE variety = ' Lagrein '

or expressed as a PHP statement:
$query = "SELECT * FROM wines WHERE variety = ' $variety '";

Technically, quotes are not needed for numeric values. But if you don't mind enclosing a value in quotes such as a wine, and if your user enters a null value into your form, you will see a query similar to the following:
SELECT * FROM wines WHERE vintage =

Of course, this query is syntactically invalid, but the following syntax is valid:
SELECT * FROM wines WHERE vintage = '

The second query will (presumably) not return any fruit, but at least it will not return an error message.
v. Check the type of user-submitted value
As we have seen from the previous discussion, the main sources of SQL injection so far have often been in an unexpected form entry. However, when you provide a way for users to submit certain values through a single table, you should have a considerable advantage to
Decide what kind of input you want to make-this makes it easier for us to check the validity of the user's entry. In previous articles, we have discussed such a checksum problem; So, here we simply summarize the main points we discussed at the time. If you're expecting a number, then you can use one of these techniques to make sure that you're getting really a numeric type:
· Use the Is_int () function (or Is_integer () or Is_long ()).
· Use the GetType () function.
· Use the Intval () function.
· Use the Settype () function.
To check the length of user input, you can use the strlen () function. To check whether a desired time or date is valid, you can use the Strtotime () function. It can almost certainly ensure that a user's entry does not contain a semicolon character (unless the punctuation mark can be legally included). You can easily implement this with the help of the Strpos () function, as follows:

if (Strpos ($variety, '; ')) exit ("$variety is a invalid value for variety!");

As we mentioned earlier, as long as you analyze your user input expectations carefully, you should be able to easily check out many of the problems that exist.
Six, filter every suspicious character from your query
Although we have discussed how to filter out dangerous characters in previous articles, let us briefly emphasize and summarize the problem again:
· Do not use the MAGIC_QUOTES_GPC directive or its "behind the Scenes"-addslashes () function, which is restricted in application development, and this function requires additional steps-using the Stripslashes () function.
· In contrast, the mysql_real_escape_string () function is more commonly used, but it has its own drawbacks.