This section will explain in detail the content related to file upload security, as a section in my column "WEB Security Principles and Interpretation of Multiple Defense Methods".
The functions of the WEB website often involve various operations such as adding, deleting, modifying and checking files, such as file uploading, file reading, file modification, and file deletion. In addition, operations on files in the WEB include file inclusion, directory traversal, and so on. This chapter will first introduce the security issues in file upload.
File upload is a common function in WEB websites. For example, websites have the function of uploading avatars, writing microblogs, and blogging can upload pictures, etc. Figure 1 is the image upload function of CSDN: Figure
1
Vulnerability principle of file upload
Most of the file uploads in the WEB type are implemented using the protocol RFC1867 , as shown in Figure 2:
This document is an extension of the HTTP protocol to meet the requirements of uploading files in HTML web pages. There are also some applications that use the HTTP PUT method to upload files. For details, see the HTTP protocol RFC2616 , as shown in Figure 3 below:
Figure 3
The file upload vulnerability often refers to the failure to control the type and content of the uploaded file, which will lead to unauthorized operations using the uploaded malicious file.
The most classic exploitation scenario is to upload an executable Trojan file in the uploaded location. This behavior usually does not cause problems immediately, but if the file can be executed remotely in some way, it will cause the machine to be controlled by malicious programs. File uploads are most commonly targeted at WEB-type servers, so usually an attacker uploads a webshell-type file. Due to the characteristics of WEB itself, it is possible to visit the WEBSHELL in the forward direction, establish a connection, and thus control the machine.
Example of file upload vulnerability
It should be said that file upload vulnerabilities used to be very common, but with the popularization of the framework and the improvement of security awareness, there are fewer and fewer file upload vulnerabilities caused by no filtering. However, the vast majority of programmers still do not have enough awareness of secure coding. At present, the protection against file upload vulnerabilities still relies on some mechanisms provided by some frameworks, so improper handling of the framework itself will lead to serious consequences. At present, the reasons for file upload security are more concentrated on the negligence of some subtleties of the framework. The following introduces several file upload vulnerabilities that have a relatively large impact
CVE-2011-2202
The vulnerability is due to the improper handling of filename in the version before PHP5.3.7 when parsing the filename in the HTTP request, resulting in the upload of the file by constructing an absolute filename path, as shown in the introduction in NVD in Figure 4 below: Figure 4 shows the source code of
the
vulnerability It is the main/rfc1867.c file of PHP, which is the specific implementation of the aforementioned RFC1867 protocol. Since this vulnerability is a vulnerability of PHP itself, it can be said that it affects all websites that use PHP to parse file uploads. Although NVD's score is not very high, I personally think that this vulnerability is a very serious vulnerability in terms of impact, PHP process level, and file upload consequences. The following is a further analysis of the vulnerability based on the patch and exp provided by NVD. The corresponding link is shown in Figure 5: in
Figure 5
, the exp (the exploit of the vulnerability) is shown in Figure 6:
The exp in Figure 6
shows that as long as the absolute path is used in the filename, that is, the path beginning with a forward slash can be bypassed, and the upload of the absolute path can be bypassed. Compare the patch content of the vulnerability, as shown in Figure 7 below : From the comparison of the patch in
Figure 7 , the repaired version
only has an extra judgment of equals when comparing the pointers. , the value of s is equal to the value of filename in the case of an absolute path, such as /home/webapp, so in the vulnerable version, the value of filename will be directly used to write the file. The programmer's intention is to take the file name, not the path name, and store it in the specified directory.
CVE-2020-17518
This vulnerability does not properly process the filename when parsing the filename in the HTTP request in Apache Flink1.5.1 to 1.11.3, resulting in the upload of the file through the relative filename path, as shown in Figure 9 NVD below:
Figure 9
Since apache flink is an open-source project, go to the corresponding commit in Figure 9 to view the source code records that fixed the vulnerability at that time. Here , as shown in Figure 10:
Figure 10
can be seen from the repair notes in Figure 10. In the version, the uploaded file name is not filtered, and fileUpload.getFilename() is used directly, resulting in a relative path bypass problem. In the repaired version, the File class is used to remove relative path information. The corresponding EXP is shown in Figure 11 below:
Figure 11
compares the relative path in Figure 11 and the source code in Figure 9. It is easy to understand the cause of the vulnerability. At the same time, it is recommended to use the environment in vulhub to verify by itself to deepen the understanding of the vulnerability. Since the original intention of apache flink is to store the uploaded files in a fixed directory, now there is a bypass through the relative path, which will cause arbitrary file uploads.
In a general sense, we discuss file uploads, usually referring to WEB-type file uploads, but in some non-WEB services, there are also file upload vulnerabilities, such as CVE-2010-2729, which are a little more difficult to analyze . Big, you can take a look if you are interested.
Potential hazards of file uploads
In the previous section, we briefly explained the file upload from the two aspects of principle and example, and what consequences will the file upload lead to. It should be said that different specific vulnerabilities have different impacts. Some file upload vulnerabilities have a small impact due to restrictions on file types, while others have no restrictions and have a greater impact. The following lists the potential harm of file upload vulnerabilities:
- Upload script files, such as php, asp, jsp, if there are files uploading these executable scripts, you can connect the uploaded scripts forward, so as to establish a webshell connection, control the target machine, and obtain the authority of the WEB user.
- Upload static files such as html classes, although this type of file will not directly have a great impact on the script type webshell. However, if the static file contains redirected phishing websites, the legitimacy of the domain name of the target server is used, and the URL address of the uploaded file is used to induce clicks and spread phishing websites, which indirectly affects.
- Upload executable files, usually Trojan files. But without permission, the Trojan cannot be executed. Therefore, the purpose of this type of upload is generally to induce downloads, spread Trojan horses, and so on.
This article is an original article by the youth in the village of CSDN, and may not be reproduced without permission. The blogger links here .