First, Introduction
PHP is a powerful but fairly easy-to-learn server-side scripting language that even inexperienced programmers can use to create complex, dynamic Web sites. However, it often has many difficulties in achieving the secrecy and security of Internet services. In this series of articles, we'll show readers the security background and PHP-specific knowledge and code necessary for Web development-you can protect the security and consistency of your own Web applications. First, let's briefly review server security-showing how you can access private information in a shared hosting environment, leaving developers out of production servers, maintaining up-to-date software, providing encrypted channels, and controlling access to your system.
Then, we discuss the pervasive vulnerability in PHP scripting implementations. We'll explain how to protect your scripts from SQL injection, prevent cross-site scripting and remote execution, and block "hijacking" of temporary files and sessions.
In the last article, we will implement a secure Web application. You will learn how to authenticate users, authorize and track application usage, avoid data loss, securely execute high-risk system commands, and be able to use Web services securely. Whether you have enough PHP security development experience or not, this series of articles will provide you with a wealth of information to help you build more secure online applications.
ii. What is SQL injection
Storing them in a database is meaningless if you are going to never use some data, because the database is designed to easily access and manipulate the data in the database. However, if you simply do this, it can lead to a potential disaster. This is not primarily because you may accidentally delete everything in the database, but because when you try to complete an "innocent" task, you may be "hijacked" by someone-using his own destructive data to replace your own data. We call this substitution "injection."
In fact, whenever you ask for user input to construct a database query, you are allowing the user to participate in building a command to access the database server. A friendly user may feel satisfied with this operation, however, a malicious user will try to find a way to distort the command, causing the distorted command to delete the data and even make more dangerous things. As a programmer, your task is to find a way to avoid such malicious attacks.
iii. How SQL injection works
Constructing a database query is a straightforward process. Typically, it will follow the following ideas. For illustrative issues only, we will assume that you have a wine database table "Wines", which has a field of "variety" (i.e. wine type):
1. Provide a form-allows the user to submit certain content to be searched. Let's assume that the user chooses to search for a wine of type "Lagrein".
2. Retrieve the user's search term and save it-by assigning it to a variable as follows:
Here is the code snippet:
$variety = $_post[' variety ');
Therefore, the value of the variable $variety is now:
Lagrein
3. Then use the variable to construct a database query in the WHERE clause:
Here is the code snippet:
$query = "SELECT * FROM Wines WHERE variety= ' $variety '";
So, the value of the variable $query now looks like this:
Here is the code snippet:
SELECT * FROM Wines WHERE variety= ' Lagrein '
4. Submit the query to the MySQL server.
5. mysql returns all records in the wines table-where the value of field variety is "Lagrein".
So far, this should be a very easy process that you are familiar with. Unfortunately, sometimes we are familiar with and feel comfortable in the process is easy to lead to complacency. Now, let's re-analyze the query we just built.
1. The fixed part of the query you created ends with a single quotation mark, which you will use to describe the beginning of the value of the variable:
Here is the code snippet:
$query = "SELECT * FROM wines WHERE variety = '";
2. Use the original invariant parts with values that contain user-submitted variables:
Here is the code snippet:
$query. = $variety;
3. Then you use another single quotation mark to connect the result-describes the end of the variable value:
Here is the code snippet:
$ query. = "'";
Therefore, the value of the $query is as follows:
Here is the code snippet:
SELECT * FROM wines WHERE variety = ' Lagrein '
The success of this construct depends on the user's input. In the example in this article, you are using a single word (or perhaps a group of words) to indicate a type of wine. Therefore, the query is built without any problems, and the result will be what you expect-a wine list with a wine type of "Lagrein". Now, let's imagine that since your users are not entering a simple type of wine type "Lagrein", they have entered the following (note including the two punctuation marks):
Lagrein ' or 1=1;
Now, you continue to construct your query using the previously pinned sections (here we show only the result values of the $query variable):
SELECT * FROM wines WHERE variety = '
Then, you connect with the value of the variable that contains the user input (in bold):
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 your expectations. In fact, your query now contains not one but two instructions, because the last semicolon entered by the user has ended the first instruction (making a record selection) and thus started a new instruction. In this case, the second instruction is meaningless except for a simple single quote, but the first instruction is not what you want to achieve. When the user puts a single quotation mark in the middle of his input, he ends the value of the desired variable and introduces another condition. Therefore, it is no longer to retrieve records that are variety as "Lagrein", but to retrieve those that meet any one of the two criteria (the first one is yours, and the second is his-variety "Lagrein" or 1 equals 1). Since 1 is always 1, so you will retrieve all the records!
You may object: Do I not use double quotation marks instead of single quotes to describe the variables that the user commits? Well, this can at least slow down the attack of a malicious user. (In previous articles, we warned you that all error notification messages should be disabled for users.) If an error message is generated here, it might just help the attacker-providing a specific explanation of why his attack failed. )
In practice, giving your users the ability to see all the records and not just part of them at first glance may seem less of a bother, but in fact, it's really a lot of trouble; seeing all the records makes it easy to provide him with an internal structure about the table, and thus provides him with an important reference for making it more vicious later. If your database does not contain information such as apparently harmless alcohol, but contains a list of the annual income of an employee, it would be particularly true to describe the situation just now.
And from a theoretical point of view, this attack is indeed a very scary thing. By injecting unexpected content into your query, this user is able to convert your database access to achieve his own purposes. So now your database is open to him-as open to you.
iv. PHP and MySQL injection
As we described earlier, PHP, from its own design, does not do anything special-except to follow your instructions. Therefore, if it is used by a malicious user, it will only "allow" specifically designed attacks as required-as we described earlier.
We will assume that you do not intentionally or even accidentally construct a destructive database query-so we assume that the problem is with the input from your users. Now, let's examine in more detail the various ways in which users might provide information to your scripts.
v. Types of user input
Today, the user's ability to influence the behavior of your scripts has become more complex.
The most obvious source of user input is of course a text entry field on the form. Using a domain like this, you are deliberately abetting a user to enter arbitrary data. Moreover, you provide a large input range to the user, and there is no way to allow you to limit the type of data a user can enter in advance (although you can choose to limit its length). This is precisely why the overwhelming majority of injected attack sources come from a form field that is not guarded.
However, there are other sources of attack, and a little bit of thinking you will think of a sneak in the form of the back of the technology-post Method! By simply analyzing the URI displayed in the browser's navigation toolbar, an observant user can easily see what information was passed to a script. Although such URIs are typically generated programmatically, there is no way to prevent a malicious user from simply entering a URI with an inappropriate variable value into a browser-and potentially opening a database that might be abused by it.
One common strategy for restricting user input is to provide a selection box in a form instead of an input box. This control forces the user to select from a set of predefined values and to some extent prevents the user from entering content that is not expected. But just as an attacker could "spoof" a URI (that is, create a URI that mimics a trustworthy but invalid one), he might imitate the creation of your form and its own version, and therefore use illegal instead of predefined security choices in the Options box. It is extremely simple to achieve this: he only needs to observe the source code and then cut and paste the source of the form-then everything opens the door for him.
After modifying the selection, he was able to submit the form, and his invalid instructions would be accepted as if they were the original instructions. As a result, the user can use many different methods to try to inject malicious code into a script.
http://www.bkjia.com/PHPjc/324885.html www.bkjia.com true http://www.bkjia.com/PHPjc/324885.html techarticle Introduction PHP is a powerful but fairly easy-to-learn server-side scripting language that even inexperienced programmers can use to create complex, dynamic Web sites. Then ...
