Processing of external data submission for security rules that cannot be violated by PHP development

Rule 1: never trust external data or enter information about Web application security. The first thing that must be realized is that you should not trust external data. External data includes any data that is not directly input by programmers in PHP code. Before you take measures to ensure security, you can GET the variable from any other source (such as GET variable, form POST, "> <LINKhref =" http :/

Rule 1: never trust external data or input

The first thing that must be realized about Web application security is that external data should not be trusted. External data includes any data that is not directly input by programmers in PHP code. Before taking measures to ensure security, any data from any other source (such as GET variables, form POST, database, configuration file, session variables, or cookies) is untrusted.

For example, the following data elements can be considered safe because they are set in PHP.

　　Listing 1. safe and flawless code

 

 
 

  
  
Reference content is as follows:
  
  
$ MyUsername = 'tmyer ';
  
  
$ ArrayUsers = array ('tmyer ', 'Tom', 'Tommy ');
  
  
Define ("GREETING", 'Hello There'. $ myUsername );
  
  
?>
 
 

However, the following data elements are flawed.

List 2. insecure and defective code

 

 
 

  
  
Reference content is as follows:
  
  
$ MyUsername = $ _ POST ['username']; // tainted!
  
  
$ ArrayUsers = array ($ myUsername, 'Tom ', 'Tommy'); // tainted!
  
  
Define ("GREETING", 'Hello There'. $ myUsername); // tainted!
  
  
?>
 
 

Why is the first variable $ myUsername defective? Because it is directly from form POST. You can enter any strings in this input field, including malicious commands used to clear files or run previously uploaded files. You might ask, "isn't it possible to avoid this risk using a client that only accepts letters of A-Z (Javascr into pt) form validation script ?" Yes, this is always a good step, but as you will see later, anyone can download any form to their machine and modify it, then resubmit any content they need.

The solution is simple: you must run the cleanup code on $ _ POST ['username. Otherwise, $ myUsername may be contaminated at any other time (such as in an array or constant.

A simple method for clearing user input is to use a regular expression to process it. In this example, only letters are allowed. It may be a good idea to limit a string to a specific number of characters, or to require that all letters be in lowercase.

Listing 3. making user input secure

 

 
 

  
  
Reference content is as follows:
  
  
$ MyUsername = cleanInput ($ _ POST ['username']); // clean!
  
  
$ ArrayUsers = array ($ myUsername, 'Tom ', 'Tommy'); // clean!
  
  
Define ("GREETING", 'Hello There'. $ myUsername); // clean!
  
  
Function cleanInput ($ input) {$ clean = strtolower ($ input );
  
  
$ Clean = preg_replace ("/[^ a-z]/", "", $ clean );
  
  
$ Clean = substr ($ clean, 0, 12); return $ clean;
  
  
}
  
  
?>