Most application systems have the function of uploading pictures or files. The attacker uses these functions to upload a web Trojan. If the directory where the uploaded file is stored has the permission to execute the script, the attacker can directly obtain a WebShell and then control the Web server. This vulnerability has two necessary conditions, one is that the Trojan can be uploaded, and the other is that the directory where the uploaded file is stored has the permission to execute the script. Uploading is a functional requirement of the business. Even if there are various security filters to limit the upload of Trojans, there are various attack methods to bypass the filtering, which are more difficult to limit. Therefore, the key to the vulnerability lies in whether the uploaded directory has the permission to execute the script. Many designers will store the uploaded file on the same server or even in the same directory as the Web application based on the consideration of cost reduction. The directory also has the same permissions to execute scripts as the web application, which leads to a high-risk upload vulnerability in the system.
There are two ways to fix this security vulnerability. One is to design the location for storing uploaded files on another file server or database that only has storage function, separate from the Web application server, so that even if the Trojan is uploaded, it will not be affected by the file. The server cannot execute the script and there is no way to carry out the attack. The second is to modify the permissions to execute the script in the directory where the uploaded file is stored.
chmod 666 /directory1/directory2/*
chmod 666 /dir1/dir2/*/*
(666 means that all users only have permission to read and write files in this directory and not have permission to execute scripts)
This removes the execute permission on the file but not on the directory, because if the execute permission on the directory is revoked, the directory cannot be accessed.