Rule 1: Never trust external data or input
The first thing you must realize about WEB application security is that you should not trust external data. External data (outside) includes any data that is not directly entered by the programmer in the PHP code. Any data from any other source (such as GET variables, form POST, database, configuration files, session variables, or cookies) is untrusted until measures are taken to ensure security.
A simple way to clean up user input is to use a regular expression to handle it.
Rule 2: Disable PHP settings that make security difficult to implement
You know you can't trust user input, and you should know that you shouldn't trust the way you configure PHP on your machine. For example, make sure that register_globals is disabled. If Register_globals is enabled, you might do something careless, such as replacing a GET or POST string with the same name with a $variable. By disabling this setting, PHP forces you to reference the correct variable in the correct namespace. To use a variable from a form POST, you should refer to $_post[' variable '. This will not misinterpret this particular variable as a cookie, session, or GET variable.
The second setting to check is the error reporting level. During development, you want to get as many error reports as possible, but when you deliver the project, you want to log the error to the journal file instead of on the screen. Why? Because malicious hackers use error reporting information, such as SQL errors, to guess what the application is doing. This reconnaissance can help hackers break through the application. To plug this vulnerability, you need to edit the php.ini file, provide the appropriate destination for the Error_log entry, and set the Display_errors to Off.
Rule 3: If you can't understand it, you can't protect it.
Some developers use strange syntax, or organize statements in a compact form, with short but ambiguous code. This approach can be efficient, but if you don't understand what the code is doing, you can't decide how to protect it.
Rule 4: "Defense in Depth" is a new magic weapon
Even if you use the PHP regex to make sure that the GET variable is fully numeric, you can still take steps to ensure that the SQL query uses escaped user input.
Defense-in-depth is not just a good idea, it ensures that you don't get into serious trouble.
The above describes the Excel macro security PHP Programming security summary, including the Excel macro security content, I hope that the PHP tutorial interested in a friend helpful.
