One of the most comprehensive SQL injection attacks in PHP

Abstract: The most obvious origin of user input is, of course, a text input field in the form. By applying such a domain, you are simply teaching a user to input arbitrary data. Moreover, you provide users with a large scope of input; there is no way to limit the data type that a user can input in advance (although you can choose to limit its length ). This is why most of the injection attacks come from unprotected form fields... in this series of articles, we will fully explore how to comprehensively prohibit SQL injection attacks in the PHP development environment, and provide a specific development example.

I. INTRODUCTION

PHP is a powerful but easy-to-learn server-side scripting language. even less experienced programmers can use it to create complex dynamic web sites. However, it is often difficult to achieve the confidentiality and security of Internet services. In this series of articles, we will introduce the security background necessary for web development and PHP-you can protect the security and consistency of your web application. First, let's briefly review the server security Title-show you how to access private information in a shared host environment, so that developers can leave the production server and keep the latest software, provides encrypted channels and controls access to your system.

Then, we will discuss the widespread vulnerability in PHP script implementation. We will explain how to protect your scripts from SQL injection, prevent cross-site scripting and remote performance, and prohibit the 'hijacking 'of temporary files and sessions '.

In the last article, we will implement a secure Web application. You will learn how to authenticate user identities, authorize and track application applications, avoid data loss, securely execute high-risk system commands, and securely apply web services. Whether you have sufficient PHP Security development experience or not, this series of articles will provide a wealth of information to help you build more secure online exploitation programs.

II. what is SQL injection

If you want to never use some data, it is meaningless to store it in a database. because the database is designed to facilitate access and control of data in the database. However, if you do this simply, it may lead to an ambush. This is not important because you may accidentally delete everything in the database. it is because when you try to complete an 'innocent' task, you may be hijacked by some people-use their own corrupt data to replace your own data. We call this replace 'notein '.

Actually, every time you request a user to input a database query structure, you promise to create a command to access the database server when the user participates. A friendly user may be satisfied with this control; however, a malicious user will try to invent a method to distort the command, as a result, the distorted command deletes data and even makes more dangerous tasks. As a programmer, your task is to find a way to avoid such malicious attacks.

III. how SQL injection works

Structure a database query is a very direct process. Typically, it will follow the following ideas for implementation. To clarify the title, we will assume that you have a wine database table 'Wines 'with a field 'variety' (that is, the wine type ):

1. provide a form-answer: the user submits some content to search. Let's assume that you select a wine with the search type 'lagrein.

2. retrieve the user's search term and retain it-by assigning it to a variable as follows:

$ Variety = $ _ POST ['variety'];

Therefore, the value of $ variety is:

Lagrein

3. then, apply the variable to construct a database query in the WHERE clause:

$ Query = 'select * FROM wines WHERE variety = '$ variety '';

Therefore, the value of the variable $ query is as follows:

SELECT * FROM wines WHERE variety = 'lagrein'

4. submit the query to the MySQL server.

5. MySQL returns all records in the wines table. The value of the variety field is 'lagrein '.

So far, this should be a very easy process that you are familiar. Unfortunately, sometimes the process we are familiar with and comfortable with easily leads to pride. Now, let's analyze the query we just created.

1. the fixed part of the query you created ends with a single quotation mark. you will apply it to describe the beginning of the variable value:

$ Query = 'select * FROM wines WHERE variety = '';

2. apply the original fixed parts and the values of the variables submitted by the user:

$ Query. = $ variety;

3. then, you apply another single quotation mark to connect to this result-the end of describing the variable value:

$ Query. = ''';

Therefore, the value of $ query is as follows:

SELECT * FROM wines WHERE variety = 'lagrein'

The structure is successfully attached to user input. In this example, you are using a single word (or a group of words) to indicate a type of wine. Therefore, the construction of this query has no title, and the results will also be what you will see-a wine list with a wine type of 'lagrein. Now, let us imagine that since your users are not imported into a simple type of 'lagrein' wine, they are imported into the following content (note that there are two punctuation marks ):

Lagrein 'or 1 = 1;

Now, you can apply the previous fixed part to structure your query (here, we only show the result value of the $ query variable ):

SELECT * FROM wines WHERE variety ='

Then, you connect the value of the variable containing the user input content to it (shown in bold here ):

SELECT * FROM wines WHERE variety = 'lagrein' or 1 = 1;

Finally, add the following quotation marks:

SELECT * FROM wines WHERE variety = 'lagrein' or 1 = 1 ;'

As a result, the query results are quite different from those of your period. In fact, your query contains not one but two commands. because the last semicolon entered by the user has ended the First Command (for record selection), a new command is started. In this example, the second instruction has no meaning except a simple single quotation mark. However, the first instruction is not what you want to implement. When a user places a single quotation mark in the middle of his input content, he ends the variable value of the period, and introduces another condition. Therefore, it is no longer to retrieve the records whose variety is 'lagrein', but to retrieve any of the records that meet the two criteria (the first one is yours, the second is the record whose-variety is 'lagrein' or 1 is 1. Since 1 is always 1, you will retrieve all records!

You may disagree: I will not use double quotes instead of single quotes to describe the variables submitted by the user? Yes, it can at least reduce attacks by malicious users. (In previous articles, we have prompted you that all error notifications to users should be forbidden. If an error message is generated here, it may help the attacker to provide a detailed explanation of the cause of the attack failure .)

In practice, it seems difficult for your users to see all the records, not just some of them. but in fact, it does take a lot of time; we can see that all the records can easily provide him with the internal structure of the table, which also provides him with an important reference for him to achieve a more vicious target in the future. If your database does not contain information such as apparently harmless wines, but a list containing employees' yearly receipts, the situation described above will be especially true.

From a theoretical perspective, this attack is indeed a terrible thing. Because unexpected content is injected into your query, this user can achieve the conversion of your database access to achieve his own goals. So now your database is open to him-just as it is open to you.

4. PHP and MySQL injection

As we described earlier, PHP, in terms of its own design, has not done anything special-except for your instigation. Therefore, if it is used by a malicious user, it is only a specially designed attack according to the request 'accept'-as we described earlier.

We will assume that you will not intentionally or even accidentally structure a database query with corrupt consequences-so we assume that the title is in the input from your users. Now, let's take a closer look at the various ways that users may provide information to your scripts.

5. user input type

Nowadays, actions that can affect your scripts become more and more complex.

The most obvious reason for user input is, of course, a text input field in the form. By applying such a domain, you are simply teaching a user to input arbitrary data. Moreover, you provide users with a large scope of input; there is no way to limit the data type that a user can input in advance (although you can choose to limit its length ). This is why most injection attacks come from unprotected form fields.

However, there are other attack sources, and you will think of a POST method that is a kind of technique that is potential in the form background! By simply analyzing the URI displayed in the browser's navigation toolbar, a user who is good at observation can easily see what information is passed to a script. Although such a URI is inherently programmed, there is no way to prohibit a malicious user from simply inputting a URI with an inappropriate variable value into a browser-and such an ambush may lead to misuse of the URI. database.

A common policy that limits user input content is to provide a selection box in a form, rather than a input box. This control can force users to select from a set of predefined values, and prevent users from seeing content during the input period to a certain extent. However, just as an attacker may 'foo' a URI (that is, creating a URI that can mimic a trusted but invalid URI, it may also mimic the creation of your form and its own version, and therefore apply illegal rather than predefined security options in the option box. To achieve this, it is extremely simple; he only needs to observe the source code, cut and paste the source code of the form-and then open the door for him.

After correcting the selection, he can submit the form and receive invalid commands, just as they are original commands. Therefore, this user can apply many different methods to try to inject malicious code into a script.

The above is one of the content that comprehensively bans SQL injection attacks in PHP. For more information, see PHP Chinese website (www.php1.cn )!