File upload vulnerability attack and prevention method
File upload vulnerability introduction:
File upload vulnerability is a form of vulnerability commonly used in web security. It is an attack on the principle of data and code separation. As the name implies, the upload vulnerability is a high-risk vulnerability where the attacker uploaded an executable file such as a Trojan, virus, malicious script, WebShell, etc. to the server for execution, and finally obtained the website control authority.
File upload vulnerability hazards:
Compared with SQL injection or XSS, the upload vulnerability is more risky. If the upload vulnerability exists in the web application, the file uploaded by the attacker is the web script language, and the web container of the server interprets and executes the script uploaded by the user, resulting in code execution. If the uploaded file is Flash's policy file crossdomain.xml, hackers use it to control Flash's behavior in that domain. If the uploaded file is a virus or Trojan file, hackers use it to trick users or administrators to download and execute it. If the uploaded file is a phishing image or an image that contains a script, it will be executed as a script in some versions of the browser and used for phishing and fraud. Even an attacker can directly upload a webshell to the server to completely control the system or paralyze the system.
Principle of file upload vulnerability:
Most websites and application systems have an upload function, and programmers do not consider the legality of the file format suffix or whether they only use js for suffix verification at the front end when developing any file upload function. At this time, the attacker can upload a dynamic script of malicious code corresponding to the scripting language of the website, such as (jsp, asp, php, aspx file suffix) to the server to access the malicious code contained in these malicious scripts for dynamic analysis To achieve the effect of executing malicious code, further affecting server security.
File upload vulnerability bypass techniques:
Generally speaking, the detection part of the file upload process consists of client-side JavaScript detection, server-side Content-Type type detection, server-side path parameter detection, server-side file extension detection, and server-side content detection. But these tests are not perfect and all have bypass methods.
Client detection bypass (js detection):
Use firebug to disable js or use burp proxy tool to easily break through.
Server-side MIME detection bypass (Content-Type detection):
use burp proxy to modify Content-Type parameters
Server-side extension detection bypass:
File name case bypass, such as Php, AsP and other similar file
names, double suffix name nesting, such as pphphp, asaspp, etc.
You can use the system to make default modifications to some special file names. Feature bypass
You can use vulnerabilities in the asp program, use truncation characters to bypass
You can use the synonym suffix name that is no longer in the blacklist list but can successfully execute the limitation of the blacklist
can be bypassed. You can use the analysis / containment vulnerability to upload a code injection Bypassing whitelisted files Bypassing
server-side content detection:
By adding a normal file identifier or other key characters to the
file Bypassing file loading detection bypassing, rendering load testing
Code injection bypassing, secondary rendering testing
Server parsing vulnerability:
Apache parsing vulnerability:
Apache's rule for parsing files is to judge parsing from right to left. If the suffix is unrecognizable file parsing, then judge to the left. For example, test.php.owf.rar ".owf" and ".rar" These two suffixes are apache unrecognizable parsing, and apache will parse wooyun.php.owf.rar into php.
If a file name is abc.x1.x2.x3, Apache will start parsing from x3. If x3 is not a resolvable extension, it will parse x2 forward and back until it can encounter a file name that can be resolved.
IIS parsing vulnerability:
In some versions of test.asp / jkl, IIS will be directly parsed as asp; test.asp; jkl, some versions of IIS will also be parsed according to asp; any file name / any file name.php, some IIS The version will be parsed directly as php.
IIS6.0 has two parsing vulnerabilities when parsing asp. One is that if any directory name contains .asp strings, then all files in this directory will be parsed according to asp, and the other is that the file name contains asp; it will take precedence. Resolved as asp.
IIS7.0 / 7.5 has a parsing vulnerability similar to Nginx for php parsing. As long as any file name is appended with a string / any file name after the url, php will be parsed according to php.
For example, upload test.jpg, and then visit test.jpg / .php or test.jpg / abc.php and a sentence Trojan shell.php will be generated in the current directory
Nginx parsing vulnerability:
Write shell statements such as <? PHP fputs (fopen ('shell.php', 'w'), '<? Php eval ($ _ POST [cmd])?>');?>
In the text xx.txt ( Or the shell statement directly writes a sentence Trojan, directly connected with a kitchen knife, chnife, etc., but it is easy to be killed), and then use the command to attach the shell statement to the normal picture xx.jpg and copy xx.jpg / b + xx.txt / a test.jpg
upload test.jpg, and then visit test.jpg / .php or test.jpg / abc.php The current directory will generate a sentence Trojan shell.php.
File upload vulnerability defense:
Defense during system operation:
- The file upload directory is set to be unexecutable. As long as the web container cannot parse the files under this directory, even if the attacker uploads the script file, the server itself will not be affected, so this is very important.
- Determine the file type. When judging the file type, you can combine MIME Type, suffix check and other methods. In the
file type check, the whitelist method is strongly recommended, and the blacklist method has proved to be unreliable countless times. In addition, for the processing of pictures, you can use a compression function or a resize function to destroy the HTML code that may be included in the picture while processing the picture. - Use random numbers to rewrite the file name and file path. If file upload is to execute code, users need to be able to access this file. In some environments, users can upload, but cannot access. If you use a random number to rewrite the file name and path, it will greatly increase the cost of the attack. Secondly, files like shell.php.rar.rar and crossdomain.xml will be unable to attack because of renaming.
- Set the domain name of the file server separately. Due to the browser's same-origin policy, a series of client-side attacks will fail, such as uploading crossdomain.xml, uploading XSS containing Javascript and other issues will be resolved.
- Use security equipment for defense. The essence of the file upload attack is to upload malicious files or scripts to the server. Professional security equipment defends against such vulnerabilities mainly through the uploading and utilization of vulnerabilities and the upload process of malicious files. Malicious files are ever-changing, and hidden methods are constantly being updated. For ordinary system administrators, security devices can be deployed to help prevent them.
Defense at the system development stage
- System developers should have a strong sense of security, especially the use of PHP language development system. In the system development stage, the security of the system should be fully considered.
- For file upload vulnerabilities, it is best to be able to strictly check the file name and file path of the user upload on the client and server. Although the inspection of the client can be bypassed by a tool with better technology, this can also block some basic temptations. The server-side inspection is best to use the whitelist filtering method, which can prevent the case of bypassing, and also need to detect the% 00 truncation character, and the content-type of the HTTP header and the size of the uploaded file also need to be carried out an examination.
Defense during system maintenance
- After the system goes online, the operation and maintenance personnel should have a strong sense of security, actively use multiple security detection tools to scan the system security, and find and repair potential vulnerabilities in time.
- Check system logs and web server logs regularly to find intrusion traces. Regularly pay attention to the update of the third-party plug-ins used by the system. If a new version is released, it is recommended to update it in time. If the third-party plug-in is breached and there is a security vulnerability, it should be repaired immediately.
- For the open source code used by the entire website or the website built using the online framework, pay special attention to the self-examination of vulnerabilities and the update of software versions and patches. The upload function is optional and can be deleted directly. In addition to the maintenance of the system itself, the server should be properly configured, and the optional permissions for the general directories should be removed. The upload directory can be configured as read-only.
