PHP Security-Filter input

Filter input

Filtering is the foundation of Web application security. It is the process of verifying the legitimacy of your data. By confirming that all data is filtered at input, you can avoid contaminated (unfiltered) data being into trusting and misused in your program. The vulnerability of most popular PHP applications is ultimately due to the lack of proper filtering of the inputs.

The filter input I mean refers to three different steps:

L Recognition Input

L Filter Input

L distinguish filtered and contaminated data

Take the recognition input as the first step because if you don't know what it is, you won't be able to filter it correctly. Input refers to all data originating from outside. For example, all from the client is input, but the client is not the only external data source, others such as databases and RSS feeds are also external data sources.

The data entered by the user is easily identifiable, and PHP uses two super-common arrays $_get and $_post to hold user input data. Other inputs are more difficult to identify, for example, many elements in the $_server array are manipulated by the client. It is often difficult to confirm which elements of the $_server array make up the input, so the best approach is to treat the entire array as input.

In some cases, what you take as input depends on your point of view. For example, session data is stored on the server, and you may not think the session data is an external data source. If you hold this view, you can save the session data in the inside of your software. It is wise to realize that the security of the session's location is linked to the security of the software. The same idea can be extended to the database, and you can also think of it as part of your software.

In general, it is safer to think of the session save location and database as input, and this is what I recommend in all important PHP application development.

Once you've identified the input, you can filter it. Filtering is a somewhat formal term that has many synonyms, such as validation, cleaning, and purification, in ordinary expressions. Although the terminology used by these people is slightly different, they all refer to the same treatment: prevent illegal data from entering your application.

There are many ways to filter data, some of which are high security. The best way to do this is to think of filtering as a process of checking. Please do not attempt to correct the illegal data, to let your users follow your rules, history proves that trying to correct illegal data often leads to security breaches. For example, consider the following method of trying to prevent directory spanning (access the upper-level directory).

CODE:

<?php   $filename = Str_replace ('.. ', '. ', $_post[' filename ']);   ? >

You can think of $_post[' filename ' to get a value to make $filename the path to the user's password file in the Linux system. /.. /etc/passwd?

The answer is simple:

  .../.../etc/passwd

This particular error can be replaced repeatedly until it is not found:

CODE:

  <?php  $filename = $_post[' filename '];  while (Strpos ($_post[' filename '], ' ... ') =  =false)  {    $filename = Str_replace ('.. ', '. ', $filename);  }  ?>

Of course, the function basename () can replace all of the above logic, and it can be more secure to achieve the purpose. But the important point is that any attempt to correct illegal data can lead to potential errors and allow illegal data to pass. Checking only is a safer option.

This point deep experience, in the actual project once encountered such a thing, is a user registration and login system changes, customers want to have a space before and after the user name can not log in, the results of the changes to the user login program changed, Use the trim () function to put the input of the user name before and after the space is removed (the typical kind do bad things), but in the registration is still allowed before and after the space! The results are conceivable.

In addition to filtering as an inspection process, you can also use the whitelist method when possible. It means that you need to assume that the data you are examining is illegal unless you can prove it to be legal. In other words, you'd rather err on the watch. Using this method, an error will only cause you to treat legitimate data as illegal. Even if you don't want to make any mistakes, it's much safer to think of illegal data as legitimate data. By reducing the losses caused by mistakes, you can improve the security of your application. Although the idea is natural in theory, history proves that this is a valuable method.

If you can identify and filter the input correctly and reliably, your work is basically done. The final step is to use a naming convention or other method that can help you correctly and reliably differentiate between filtered and contaminated data. I recommend a relatively simple naming convention because it can be used in both process-oriented and object-oriented programming. The naming convention I used was to put all the filtered data into a data called $clean. You need to use two important steps to prevent the injection of contaminated data:

L often initialize $clean as an empty array.

L join to check and block variables from external data sources named clean,

In fact, only initialization is crucial, but it's also good to get into a habit: All variables named clean are considered your filtered data array. This step reasonably ensures that the $clean contains only the data that you intentionally saved, and that you are only responsible for not having contaminated data in $clean.

To consolidate these concepts, consider the following form, which allows the user to select one of three colors;

CODE:

<form action= "process.php" method= "POST" > Please  Select a color:  <select name= "Color" >    < Option value= "Red" >red</option>    <optionvalue= "Green" >green</option>    < Optionvalue= "Blue" >blue</option>  </select>  <input type= "Submit"/>  </form >

In the programming logic of handling this form, it is very easy to make the mistake of thinking that only one of the three choices can be submitted. In the second chapter you will learn that the client can submit any data as a value of $_post[' color '. In order to properly filter the data, you need to use a switch statement:

CODE:

  <?php   $clean = Array (  );  Switch ($_post[' color ') {case '    Red ': Case '    green ': Case    ' Blue ':      $clean [' color '] = $_post[ ' Color '];      break;  }   ? >

In this example, $clean is first initialized with an empty array to prevent the inclusion of contaminated data. Once the $_post[' color ' is shown to be red, green, or one of blue, it is saved to the $clean[' color ' variable. Therefore, you can be sure that the $clean[' color ' variable is legal and uses it in other parts of the code. Of course, you can also add a default branch to the switch structure to handle illegal data. One possibility is to display the form again and prompt for errors. Be especially careful not to try to export contaminated data for friendliness.

The above method is useful for filtering data with a known set of valid values, but it is not helpful to filter data that has a known set of valid characters. For example, you might need a user name that consists only of letters and numbers:

CODE:

<?php   $clean = Array (  );   if (Ctype_alnum ($_post[' username '))  {    $clean [' username '] = $_post[' username '];  }   ? >

Although regular expressions can be used in this case, using PHP built-in functions is more perfect. The likelihood that these functions contain errors is much lower than the likelihood that your self-written code will go wrong, and an error in the filtering logic almost means a security breach.

The above is the PHP security-filter input content, more relevant content please pay attention to topic.alibabacloud.com (www.php.cn)!

