Possible attacks and solutions during Apache mode installation

When PHP is installed as an Apache module, it will inherit the permissions of the Apache user (usually "nobody"). This has some implications for security and authentication. For example, if you use PHP to access a database, unless the database has its own access control, the "nobody" user must be able to access the database. This means that a malicious script can access and modify the database without providing a username and password. It's entirely possible for a web spider to stumble upon a database's administration page and delete all databases. You can avoid this problem through Apache authentication, or design your own access model using technologies such as LDAP, .htaccess, and use these codes as part of the PHP script.

Usually, once the security reaches a level where the risks borne by PHP users (here, Apache users) are minimal, PHP may have reached the point where it prevents writing any files to the user directory or prohibits access and modification of the database. . This means that whether it is a normal file or an abnormal file, whether it is a normal database transaction or a malicious request, it will be rejected.

A common mistake that is detrimental to security is to allow Apache to have root privileges, or to give Apache more powerful functions through other means.

Elevating the permissions of the Apache user to root is extremely dangerous and may compromise the security of the entire system. So unless you are a security expert, never consider suing, chrooting or running with root privileges.

In addition, there are some simpler solutions. For example, you can use open_basedir to limit which directories can be used by PHP. You can also set up Apache-specific zones to restrict all web activity to non-user and non-system files.