Home > Article > Backend Development > Summary of PHP programming security_PHP tutorial
Summary of PHP programming security_PHP tutorial
- WBOYOriginal
- 2016-07-21 15:41:171016browse
Rule 1: Never trust external data or input
The first thing you must realize about web application security is that external data should not be trusted. External data includes any data that is not entered directly by the programmer in the PHP code. Any data from any other source (such as GET variables, form POST, databases, configuration files, session variables, or cookies) cannot be trusted until steps are taken to ensure security.
A simple way to sanitize user input is to use regular expressions to process it.
Rule 2: Disable PHP settings that make security difficult to implement
Now that you know you can’t trust user input, you should also know that you shouldn’t trust the PHP configuration on the machine. Way. For example, make sure register_globals is disabled. If register_globals is enabled, it's possible to do careless things like use a $variable to replace a GET or POST string with the same name. By disabling this setting, PHP forces you to reference the correct variables in the correct namespace. To use variables from a form POST, $_POST['variable'] should be quoted. This way you won't mistake this particular variable for 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 the errors to be logged to a log file rather than displayed on the screen. Why? Because malicious hackers can use error reporting information (such as SQL errors) to guess what an application is doing. This kind of reconnaissance can help hackers breach the application. To close this vulnerability, edit the php.ini file to provide a suitable destination for the error_log entries and set 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 very compactly to form a short but meaningful Obscure code. This approach may 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 the new magic weapon
Even if you use PHP regex to ensure that GET variables are entirely numeric, you can still take steps to ensure that SQL queries use Escaped user input.
Defense in depth is not just a good idea, it ensures that you don’t get into serious trouble.