Design Secure File Upload Functions

Add this article to the favorites of simple programmers

Author: thorn

In the past two days, our old friend PDP gave a speech on GIFAR at BlackHat 08. As usual, PDP is very cumbersome. The topic is about how to bind a GIF or JPG file with a JAR file, and then cheat the server to think it is a GIF or JPG file. The result is an example of executing a JAR file in the client's JVM.

He also gave some examples of spoofing. For example, in office2007, the doc file is actually in the zip format and contains some xml files, so he packed the jar file in the zip file, then change the suffix to doc to fool the target.

Here is the client problem. I think of other problems, such as secure upload.

Based on past experience, we may design the following file upload security rules:
1. Set the File Upload directory to unexecutable.
2. Determine the file type
3. Set the domain name of the file server separately
4. Rewrite the file name. The file path is unpredictable.

The first rule is obvious to reduce the risk of executing dynamic language scripts. If a webshell is successfully uploaded but cannot be executed, it can still play the role of in-depth defense.

Second, when determining the file type, we generally require a whitelist instead of a blacklist, because the blacklist may be incomplete and may cause some risks of bypass.

For example, in earlier FCKEditor versions, this problem has been solved only by blacklisting and finally bypass.

Apache has a feature that resolves the file suffix after the first "." As the file type. For example, fvck.php.rar.rar.rar will be parsed by apache as fvck. php. I recently read the php manual. In the installation documentation, I have a special guide for this problem:

15. Tell Apache to parse certain extensions as PHP. For example, lets have
Apache parse. php files as PHP. Instead of only using the Apache AddType
Directive, we want to avoid potentially dangerous uploads and created
Files such as exploit.php.jpg from being executed as PHP. Using this
Example, you cocould have any extension (s) parse as PHP by simply adding
Them. Well add. phtml to demonstrate.

<FilesMatch. php $>
SetHandler application/x-httpd-php
</FilesMatch>
IIS6 also has this similar feature, that is, when the folder name is fvck. asp (fvck can be replaced with any value), any file in this folder will be executed as asp,
So far, it seems that Microsoft has not seen any signs of fixing this feature as a bug.
Therefore, if you are not familiar with the features of these webservers, you may think that the vulnerability is so amazing: I have made full restrictions, why is it still "push-ups?
When determining the file type, most programs use the method of checking the file suffix. Here, we mainly need to note that hacking trick is the result of checking whether some functions end with 0 bytes, similar vulnerabilities have been detected on the Internet in the past, uploading fvck.jpg % 00. asp can bypass the file type check.

I have also seen that only the file header is checked. This is also a good fool. Construct a valid gif file header and paste the webshell behind it. If the suffix is valid, the same can be parsed by the browser:

GIF89a?
<? Phpinfo ();?>

The more advanced one is to perform more File Format checks, such as checking the length and width of pixels in the image, and then compress the image. The resulting images are basically distorted, some webshells are also damaged.

When checking the file format, some classes that have been encapsulated on the Internet are generally used, which is advantageous in scanning the file format. However, efficiency is obviously a matter of consideration when checking large files. Many programmers may be reluctant to choose this method for efficiency reasons.

But today, from the perspective of the cumbersome method of binding files to PDP, it seems that it is necessary to check the file format in detail, because the attacker may not only target the server, but also the client, if you want to guarantee the client, you must check the file format in detail so that it falls into the whitelist.

Third, setting the file server domain name separately is also a protection for the client. This may avoid many cross-origin problems. If XSS occurs, attackers may need to break through the cross-domain restrictions to further expand the results. For example, if crossdomain. xml is uploaded, it may cause cross-domain flash problems, which are real risks.

Fourth, rewrite the file name and random file path. This is to hide the risks. Now, programmers who do their best will do so. This is also a very effective way to minimize the risk.

It should be noted that the algorithm for constructing random file names or paths should be "random", instead of directly retrieving a hash from a part such as a cookie. It is better to use functions like random () to generate on the server. I believe programmers still have this consciousness and will not repeat it.