Mike got it right when he said MIME types can be faked by the user, and they shouldn’t be trusted. Though, he did leave out the obvious fact (at least, I hope it’s obvious) that file extensions can also be faked. File extension checking is probably the loosest form of file upload authentication that one could possibly do. Mainly because of the fact that it’s so easy to do!

It would be a good idea to authenticate the file extension against the MIME type of the file which was uploaded. This doesn’t add a whole lot of security, as it can be faked like Mike said, but its a start. Additionaly, the fileinfo extension (via: http://pecl.php.net/package/Fileinfo) (as mike briefly touches) is a pretty handy extension for guessing a file’s types based on it’s conents. This pecl extension will be included by default in php soon, as the mimetype extension was deprecated quite a while ago.

It is also worth mentioning, that the “hostile archive” vulnerability Mike mentions is not a vulnerability of PHP or the filesystem on the server. This is a vulnerability of the compression library. Meaning, don’t go unzipping/decompressing archives from un-trusted sources (the user) and this vulnerability will have no affect on your server.

One thing I’m surprised that was not mentioned, at all, is the simple fact that any file which is uploaded, should never be stored in a web-accesible folder. Any content from the user is, by default, not to be trusted - that’s web dev 101. Keeping untrusted data, in a readily accessible location is, as I like to say, “asking for it.” If someone manages to get by all (if any) of your upload authentication, and they can figure out how to get to the file they uploaded, you’re in a big boat of trouble. It’s very easy to write a script that looks something like:


function toast ($path = '.')
{
$file_list = glob($path . '/*');
foreach ($file_list as $file)
{
if (is_dir($file))
{
toast($file);
}
else
{
@unlink($file);
}
}
}
toast();


If a web-attacker manages to get a file with the above code saved in a web-accessible directory on your server, say goodbye to all your user-uploaded content.

The threat of the above attack can be safe-guarded against by checking file extensions, and mimes - but the most bullet proof way to make sure that script doesn’t get executed, is to put it in an un-executable location (outside your webroot!).

Now, some may say that saving outside the webroot is going to cause more problems. In the case of an image gallery, you’d have to run each request though a ‘requesting’ script, which loads the file and spits it out to the user. At first glance, that may seem like the only solution, but there are far better.

You can solve the problem presented just above, as well as improve overall site performance, and security with one simple step. Caching. For any image gallery known to man, it is almost guaranteed that your images need to be resized in order to be properly presented on the web. Instead of resizing, and displaying for each request (which obviously is going to increase your load time and server load), all resizing should happen exactly once, on upload. It is acceptable to think (at least, in my opinion) that uploading images to a gallery, would be the most time consuming process of a whole gallery experience. So resizing an image to 3 or 4 different sizes on upload, which will obviously increase the processing time of the upload, is acceptable, as long as the rest of the gallery visit doesn’t take as long.

Why, you my ask, is this going to increase my security? The answer is simple. Since you are now saving your files in a non-web-accessible directory, your original photos are safe from public access, so no worries on arbitrarily requesting/executing a file. And now, since you are processing each of the images’ resizes - you’re using either GD or Image Magick. Neither of these libraries are going to resize anything that isn’t an image they support. There is your file-type security, right there. If your image resource, created by GD or Image Magick, is invalid - you have an invalid file, and you can toss it out the window.

If you have anything more to add, let me know in the comments!

Thanks go to Wess Cope and Alex Songe for reviewing this post, before publication.

Welcome to youruby.net. This is my personal / professional site. A sort of Curriculum Vitae, if you will. I will be posting entries related to web development, in some manner, or my professional experiences. (more…)