PHP security introduction and general principles

Introduction

PHP is a powerful language. Whether installed as a module or CGI, its interpreter can access files, run commands, create network connections, etc. on the server. These features may add a lot of insecurity factors to the server, but as long as PHP is installed and configured correctly, and secure code is written, PHP can create more secure CGI programs than Perl and C. Moreover, it is also possible to find a good balance between usability and security.

PHP may be used in many different ways, therefore, PHP has built-in options to easily configure it. Although the numerous options allow PHP to accomplish a lot of work, the settings of these options and the configuration of the server are likely to cause security issues.

PHP’s options are as flexible as its syntax. Using PHP, you can create complete server-side programs in an environment with only shell user rights, or use it to complete server-side includes (Server-Side Includes) in a strictly restricted environment without taking too much risk. How to set up such an environment and how secure it is depends largely on the PHP developer.

This chapter starts with some general security suggestions, describing how to maximize security in different environments, and introducing some programming principles for different security levels.

General

Absolutely secure systems do not exist, so methods commonly used in the security industry help balance availability and risk. Double-validating every variable a user submits may be a responsible move, but it can result in users having to spend a lot of time filling out a complex form, forcing some users to try to bypass security.

The best security mechanism should be able to meet the needs without hindering users and increasing the difficulty of development too much. In fact, some security problems often occur in systems with such over-strengthened security mechanisms.

Don’t forget the famous principle of equal strength: the strength of a system is determined by its weakest link (equivalent to the barrel principle). If all transactions are recorded in detail based on time, location, and transaction type, and user authentication only relies on one cookie, then the credibility of the user's corresponding transaction record will be greatly weakened.

Be sure to remember when debugging code that even a simple page is difficult to detect all possible scenarios: an employee who is dissatisfied with you may not necessarily enter what you want, and hackers also have enough time. Study your system and, of course, your pet cat will jump on your keyboard. This is why all code must be inspected to discover where improper data could be introduced, and then the code can be improved, simplified, or enhanced.

The internet is full of people who will break your code, attack your website and enter shady data in order to become famous and make your life fun. Whether it is a large website or a small website, as long as it can connect to the Internet, it will become a target. Many hacking programs don't care about the size of the website and will just mechanically scan IP addresses looking for victims. We hope that's not you.