File Upload Vulnerability

1. Normal file upload function implementation

Create An ASPX file and add the following code to form:

<Asp: fileupload id = "fileupload1" runat = "server"/>

<Asp: button id = "btnupload" text = "Upload" runat = "server" onclick = "btnupload_click"/>

Write the following code in the background:

protected void btnUpload_Click(object sender, EventArgs e){string filePath = Server.MapPath("./Upload/") + fileupload1.FileName;fileupload1.SaveAs(filePath);} 

The basic upload function is complete.

 

2. Vulnerability demonstration

Prepare An ASPX file with only one line in it:

<%=DateTime.Now %>

We uploaded this file in a browser and checked it in the server directory. The file has been uploaded successfully.

The request address is as follows:

Http: // localhost/test/upload/test. aspx

As you can see, this aspx file has been executed by IIS and is no different from the aspx file we wrote.

If the file contains malicious code, the server will be attacked.

 

3. Principle Summary

The main cause of this vulnerability is only one,The uploaded file is executed by IIS as An ASPX file..

If IIS is not executed, there will be no problem. Why does IIS execute this file? There are two points:

First, the file is in the directory of the website.

Second, the file extension is aspx, which is the executable file name of IIS.

In line with these two points, the user sends a request and IIS will execute it.

 

4 solutions

When many articles talk about this vulnerability, they talk about how to control files uploaded by users, including file name check, file content verification, and packet capture tools, here I want to explain, why not consider the first point? Why put files under the directory of this website? If the first point is not met, what if it is An ASPX file? What if it is an EXE file?

To upload a file, you need to use it after it is uploaded. The directory of the file storage disk to be uploaded is directly stored in the website directory, and the user can use it immediately after it is uploaded, which is simple and convenient. What should I do if this vulnerability exists? The simplest method is:

No scripts or extensions are executed for the upload directory configuration in IIS. In this way, even the uploaded aspx file will not be executed.

In addition, the path of the file storage disk is directly fixed, which is directly equal to the specified directory + UUID. Do not use any external variable operations, such as retrieving the uploaded file name, for example, attackers are not given any chance to upload files to other directories. Simple, crude, and effective.

 

Appendix:

1. We have not compiled the upload function. Will this vulnerability occur?

Are other third-party components with the upload function used? For example, ckeditor. If you have the permission, set the permission for storing the directory of the disk.

2. Is there a vulnerability in the ajaxupload upload without refreshing the new upload?

The focus is not on the front-end technology, but on whether the uploaded files can be executed by IIS! Our goal is to prevent uploaded files from being executed.

If you are not using IIS and other programming languages, you can get twice the result with half the effort.

File Upload Vulnerability