8 Rules to Implement Secure File Uploads

The IIS semicolon file extension issue prompted me to write a number of the principles to implement file uploads firmly. this can be particularly advanced as there's sometimes no simple way to validate the content of the file.

The overall goal is to create a group of defensive layers that tightly management the method of uploading the file and later retrieval of the file. The user will continually act indirectly with the file and ne'er directly access the file system while not application control.

1. create a new file name

Do not use the user provided file name as a file name on your native system. Instead, produce your own unpredictable file name. something sort of a hash (md5/sha1) works because it is easily validated (it is simply a hex number). perhaps add a serial range or a time stamp to avoid accidental collisions. you'll add a secret to the name to form it more durable to guess the file name. If you wish to stay the original file name: use a look-up table to link the validated user equipped file name to the server created name.

2. Store the file outside of your document root

If your document root is /var/www/html, produce a directory /var/www/uploads and use it to store
uploaded files. That way, an aggressor offender be able to retrieve the file directly. this will enable you to provide fine grained access management. The file won't be parsed by the server's application language module however the supply of the file are going to be streamed.

3. Check the file size

You should set a maximum file size within the upload form, however remember: it's simply informative . certify to see the file size after the upload completed. Be particularly careful if you permit the upload of compressed files and later reconstruct them on the server. This state of affairs is extremely exhausting to secure.

4. Extensions are pointless

The motivation for this post is that the ';' issue in IIS. However, even Apache always continually behave the manner you expect it to. attempt 'something.php.x' in Apache and chances are that php code are going to be dead. Its a feature ;-) . If you stream a file back to the user, the extension is not what matters, however the Content-Type header and therefore the file's header. it's best to use the "file" command on UNIX to examine the file sort. however even this can be not fool proof. it'll simply check the primary few bytes. In PHP for instance, a file could begin with a GIF header, however later if the PHP engine sees a "it'll with happiness interpret an embedded PHP script.

5. try a malware scan

The extension is true, and you checked that the file is really a valid JPEG file per it's header. However, it might still be a malicious JPEG using one amongst the many image parser bugs to take advantage of clients downloading the file. there's no nice defense against this as way as i'm aware. One attainable work around is to "rebuild" the file. Convert the JPEG to a GIF and back to a JPEG. this may possible strip out any malicious feature. however this method might expose your servers to only constant image program bugs.

6. Keep tight control of permissions

Any uploaded file are going to be owned  by the net server. however it solely wants read/write permission, not execute permissions. when the file is downloaded, you'll apply extra restrictions if this can be acceptable. sometimes it can be useful to get rid of the execute permission from directories to prevent the server from enumerating files.

7. authenticate file uploads

File uploads, particularly if these files are seeable by others while not moderator review, need to be authenticated. this manner it's at least possible to trace who uploaded an objectionable file.

8. Limit the amount of uploaded files

Many developers limit the file size, however not all limit the amount of files uploaded in a request. certify to apply affordable limits. however be also prepared for a DoS attack that simply uploads an oversized range of tiny files. choose an acceptable directory structure to limit the amount of files per directory and choose an acceptable filing system.

Conclusion

Let me know if you'll be able to think of different problems to consider. Some rely on the application, however the eight on top of are generic. for instance, if you cope with XML files you'll be able to validate them against a schema. A document can be valid based on dictionaries. explicit image formats will be analyzed additional closely for malicious content. For PDFs, you can strip out javascript which regularly causes issues and for HTML you'll use libraries like HTML setup. using a distinct upload partition can facilitate against having a denial of service attack impact different parts of the system and it'll additionally provide extra access control. a person's moderator could also be suggested if inappropriate content is a drawback.