PHP programming Security Summary

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.

A Simple Method for clearing user input is to use a regular expression to process it.

Rule 2: Disable PHP settings that make security difficult

You already know that you cannot trust user input. You should also know that you should not trust the PHP configuration method on the machine. For example, make sure to disable register_globals. If register_globals is enabled, you may do some careless things, such as replacing the GET or POST string with the same name with $ variable. By disabling this setting, PHP forces you to reference the correct variables in the correct namespace. To use a variable from form POST, you should reference $ _ POST ['variable']. In this way, the specific variable will not be misunderstood as a cookie, session, or GET variable.

The second setting to be checked is the error report level. During development, you want to get as many error reports as possible, but you want to record errors to log files rather than display them on the screen when delivering the project. Why? This is because malicious hackers use error report information (such as SQL errors) to guess what the application is doing. This kind of reconnaissance can help Hackers break through applications. To block this vulnerability, You need to edit the php. ini file, provide an appropriate destination for the error_log entry, and set display_errors to Off.

Rule 3: if you cannot understand it, you cannot protect it.

Some developers use strange syntaxes, or organize statements very compact to form short but ambiguous code. This method may be highly efficient, but if you do not understand what the code is doing, you cannot decide how to protect it.

Rule 4: "defense in depth" is a new magic weapon

Even if PHP regex is used to ensure that the GET variable is completely numeric, you can still take measures to ensure that the SQL query uses escape user input.

Defense in depth is not just a good idea. It ensures that you are not in serious trouble.