Using server-side mime type libs is the best thing for ascertaining the type of file it is.

Using extension checking is the way you make sure you’re not writing something a cgi processor would execute (because that’s how most webservers recognize that it’s to be executed, amazingly).

Mime magic will check in a sane manner the type of file, but you will still not know if it’s a valid image file. By using gd and/or imagemagick to immediately resize the image to some type of max height and then always saving it as a jpeg is a fairly valid way. Imagemagick even has ping functions for this.

Putting stuff outside the webroot limits the visibility of the file, you don’t have to rely on the webserver’s config (or lack thereof). Though you’d have to be insane to make jpeg map to some type of cgi handler.

Instead of saying “Do these things to make your app secure” it should be said “These are some known vectors, and this is how you stop this vector” etc.

I consider putting shit outside the webroot as “Putting the gun on top of the cabinets so the kid doesn’t get to it.” It doesn’t make the gun less dangerous, it just means only the adults get to use it.

As far as reusing a MIME type which was originally specified by the client; If you validate this MIME-type before you save your file, there is no reason you couldn’t do this.

Obviously using the client specified MIME blindly is horrible, bad, and wrong as we’ve thoroughly outlined in both our posts, but this obviously isn’t common knowledge, nor is where to save files once their uploaded, or even how to validate them. I was simply saying that trusting the user, and the user’s content to be usable from the get-go is web development 101.

Thanks for responding. I do not agree on all of your points, but I will update the post for clarity.

First, the file extensions are not, in itself, a problem. You can of course upload PHP code as a .jpeg file, but what good would it do to anyone if the webserver reads it as a JPEG image and streams it to the output verbatim? The “classic” file extension vulnerabilities are an entirely different class of client-side problems: typically, a client that parses the file name is unable to do so properly (think Outlook wrapping around a long file name that is stuffed with spaces and a .pif extension in the end). This is never the case in webservers, which rely on the file extension heavily. It would take a genuinely screwed up server configuration (e.g. a default handler set to PHP for all kinds of files, something I’m not even sure is possible) to make extension faking dangerous to the server. The client is another issue, but I mentioned that.

In fact, MIME type faking is more dangerous: first, people who don’t understand HTTP do not really realize that it’s an user-supplied value; second, if you only check the file extension and not the MIME type, you’re taking a comparative risk that’s way lesser than if you were to check only the MIME type and not the file extension. In other words, MIME type tests and not file extension tests are the loosest type of verification.

I also absolutely disagree regarding the “outside the document root” policies. If your trust check fails, it really doesn’t matter whether you put the hostile file inside or outside the web root: your security has been violated anyway. On the other hand, when you move static documents out of the document root, you get a tremendous disadvantage of having to identify and pipe them to the user yourself as opposed to letting the webserver do that for you (exactly what you mentioned) - the kind of thing that a webserver is designed for and is inherently better at than any of your PHP code. You gain zero security benefit and add an unnecessary burden on the server, plus there’s now additional logic in your code that never should’ve been there in first place. Worse yet, people who succumb to the dumb idea of moving the documents out of webroot eventually fall into the trap of reusing the initial MIME type for the output headers, thus creating a goatsific security hole. It is not a web developer 101; it’s a myth.

I would not necessarily go with GD/imagemagick processing either. Remember: these libraries are context aware, which means bugs in them can be exploited. Unless you actually need to produce thumbnails, you shouldn’t use context-specific libraries to validate uploads. You are actually aggravating risks and not alleviating them.

The proper way to handle image upload locations is almost as you described, but in a production environment (on a single machine) you do it like this:

The uploaded documents are stored under a separate webroot, and are available through a subdomain, served by a different webserver (lighty or thttpd, usually), which runs under different privileges and does not have write permissions anywhere.

Uploads are authorized by a server script, and then queued in the database for a background (crontab) script with a different set of privileges. That script double checks the file contents and then moves them to the target location, where they are picked up by the other server that only serves static documents. This way, you retain complete isolation, enforce strict security, and do not get a performance impact. Better: you can do mod_rewrite magic, add caching headers, play with resource allocation between webservers according to your specific scenario or put a proxy in front of your whole static subdomain. The downside? It’s complicated. You need to be secure in your skills to set this kind of thing up and maintain it in the future.