It must be noted that a file does not have an inherent "content-type" per se. A file is a bunch of bytes, and has a name. When you download a file from a Web server, the server infers a content-type (such as "application/pdf") from whatever clues it can find, mostly the so-called "extension" (the few letters at the end of the file name; e.g. "
.pdf" is assumed to indicate a PDF file), and sometimes the file contents themselves: for instance, when a Web server distributes an HTML file, it also looks within the file header for a "meta" tag which would override the default choice for Content-type, like this:
<meta http-equiv="content-type" content="text/html;charset=UTF-8" />
So you have two operations on your server: upload, and download. Upload is mostly safe: the file comes, and is stored. Download can be a worry: when an administrator will download a file, he will do so by clicking on some link within a Web browser, and the Web server will infer a content-type, as described above. The Web browser will then use the content-type to decide what to do with the downloaded file, and this might not necessarily be "suggest to the user to save it somewhere". For instance, if someone uploads a
So you should filter the content-types under which you will serve the files when downloaded; and mind the file name, too, because even if the file is just saved on the administrator system, it may still be a
.exe file which the administrator will execute when clicking on it.
Moreover, allowing any kind of file to appear on your server may be an indirect tool to leverage an attack. There are some security holes in which the attacker can somehow force the execution of an arbitrary file on the server; an unfiltered upload mechanism allows the attacker to first push exactly the kind of executable file he would like to see executed on the server.