File upload vulnerability and hazards

File upload vulnerability refers to an executable file uploaded to the server by a network attacker. Without proper verification and processing of the file, the application may execute the upload file, leading to a security vulnerability. Most websites have the function of uploading files, such as profile pictures, pictures, videos, etc. This logic can easily trigger server vulnerabilities if not handled properly. This vulnerability is more common in programs characterized by file name URL. Well, yes, the best language in the world, PHP. For example, users upload a PHP file and can execute it after getting the address of the corresponding file, which is self-evident harm. Is there no file upload vulnerability in Node.js? The answer is definitely no. In addition to executable files, there are several potential problems.

The file name

There are two things in a file uploaded by the user that are often used by the application: the file itself and the name of the file. Be careful if file names are used to read or store content. It is likely that an attacker will construct a similar… /.. /.. /attack.jpg file name, if not carefully used directly can overwrite the server key files and crash the program, or even more likely to overwrite /etc/passwd with the attacker specified password to break the server.

Some students might say that the/and other characters are filenames illegal characters, users can not define such names. You are right, but we need to know that we do not interact with the user’s files directly, but rather get the user’s files through HTTP requests. In the HTTP form upload request, the file name is stored as a string. An attacker can construct anything in the request to submit to the server, as long as it is a legitimate HTTP request format.

POST /upload HTTP/1.1 Host: test.com Connection: keep-alive Content-Length: 4237161 Accept: */* Origin: http://test.com the user-agent: Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36 Content-Type: multipart/form-data; boundary=----WebKitFormBoundary9pQqgBGwpDfftP8l Referer: http://test.com Accept-Encoding: gzip, deflate Accept-Language: en,zh-CN; Q = 0.9, useful; Q = 0.8, useful - TW; Q = 0.7, da; Q = 0.6 -- -- -- -- -- - WebKitFormBoundary9pQqgBGwpDfftP8l Content - Disposition: the form - data; name="file"; filename=".. /.. /attack.jpg"
Content-Type: image/jpeg

------WebKitFormBoundary9pQqgBGwpDfftP8l--
Copy the code

HTML and SVG

Node.js has less vulnerability to file upload server executables than PHP, but we have client-side executables as well, so be prepared. It is assumed that users can upload files in any format, and if an attacker uploads HTML files, it can cooperate with CSRF attacks to further create XSS attacks.

If you are an image upload interface, there is also a problem if you only limit the HTML format, because one particular aspect of images is SVG. SVG is a vector graphics format that uses XML to describe images, inside which we can insert DOM tags such as < HTML >, 

< SVG viewBox = "0 0 100 100" version = "1.1" XMLNS = "http://www.w3.org/2000/svg" XMLNS: xlink = "http://www.w3.org/1999/xlink" > <script>alert(111)</script> <rect x="25" y="25" width="50" height="50" /> </svg>Copy the code

The chain of soft

We know that in an operating system a soft chain is essentially a file, but this file does not contain the actual content, it contains the pathname of another file. It can be any file or directory and can be linked to files on different file systems. If an attacker uploads a soft chain file whose description corresponds to /etc/passwd, the attacker can use the program to directly read the contents of key files on the server, causing the server to be compromised.

Server disk

In addition to the file itself, another situation we need to consider is the processing of files after they are uploaded. If we store the files uploaded by users locally without limiting the frequency of upload, it is likely to be used by attackers. The attacker will upload files frequently, causing the server disk to occupy 100%. After the server is overwhelmed, the server cannot handle other tasks of the program, leading to the server downtime.

defense

For the above possible vulnerability scenarios, we need to do the following:

  1. Whitelist filtering should be carried out when using the name of the file passed in by the user. If possible, do not use the name of the file passed in by the user to eliminate the security holes caused by the file name.
  2. Do a good job of format verification of the file content itself, the way of blacklist or whitelist can be, but the way of whitelist security will be a little higher. The file format cannot be determined simply by the suffix of the file or the form uploaded with itContent-TypeFields, because these are user-uploaded content, are constructible. It is best to read by the magic number in the file header, in conjunction with the whitelist list, to avoid this problem. The well-known module that uses magic numbers to determine file types isGithub.com/sindresorhu…, you are advised to use it directly.
  3. If the user is allowed to upload.svgTo format images, the SVG content needs to be HTML parsed and filtered out<script>.<foreignObject>And other related labels. Of course, whitelisting is best. Here’s a more complete oneWhitelist list of SVG legal labels.

It is necessary to note that if the compressed package uploaded by the user is decompressed, not only the compressed package itself must be verified according to the above rules, but all contents after decompression must be verified according to the same logic. In addition, if the server disk is overloaded, you are advised to limit the upload frequency of users to reduce risks and add disk monitoring alarms to monitor the online server status in real time. If local storage is not necessary, external storage services can be used to reduce the risk of the server.