Securely serving images

Question

A respected colleague insists that storing images on my server is insecure, especially if the file structure is easy to surmise (as we have image galleries created by the users, the naming scheme is easy to follow).

Instead he recommends storing the images above the root, and serving them using fread or fputthrough.

I cannot work out what the risks would be, or why they would be obviated when served through a script.
The overhead of such a script sounds ridiculous.

I do understand that images must be checked before being stored on the server, and to that end am using imagemagick to do a minor conversion and save to jpeg - which should get rid of any dross, as far as I would guess.

So, the questions to the great minds on SO:

1. Are there any security issues with storing images locally with easy to follow paths?
2. Is my method of vetting images with IM secure?
3. Is there a reason to use PHP to serve the images?
4. Is the overhead of using PHP really substantial?
5. Would using a CDN make a difference a far as security goes (I do NOT want to)?
6. Am I missing something?

Thanks all!

Answer 1

I suspect that what your friend is referring to is not simply serving images but rather specifically serving user-supplied images. There are a number of security issues in serving user-supplied content. In the case of images, there are a number of ways to use an image upload to get the web server to execute code. A few of the more well-known ones include:

• A "GIFAR" file. Essentially, this is a GIF file and a jar file concatenated. Because the index info for a GIF is at the beginning and that for a jar file is at the end, the two file types can be combined and the result is both a valid GIF and a valid JAR.
• Multiple file extensions. Web servers support multiple file extensions to allow for things like internationalization. For example, a file named page.html.fr might map to the French language version of a page. A file with an extension of image.php.jpg or even image.php.123 might be executable as a PHP script, depending on the configuration of the server.
• Buffer overflow. Image file formats usually contain a header at the beginning which describes the size and format of the file. Understating the size can allow malicious users to craft a buffer overflow attack.

All of these examples lead to the ability to execute code as the web server. Although the functionality of the site requires the ability to upload files, storing them in directories that are not directly accessible by a URL makes it harder to exploit them. Similarly, using a script to serve them rather than the web server's MIME handlers insures that the images are treated as a stream of data rather than a potentially executable file.

Whether this much security is ridiculous depends on the number of users, nature of the data collected about them and the triviality of the web site. At the very least, an attacker would like to get the passwords of the users because of the tendency to synchronize them. A user on your site whose password is ABC123 will probably use that same password for email, social sites and possible banking and financial sites. Beyond passwords, if the data you collect about your users is personally identifiable or has other market value, or if you simply have a large number of users, then you have to assume that the site will be a target. That means, either be more careful serving user-supplied image files, validate them really well, or both.

I don't have a good answer to whether using imagemagick will address the security concerns. At the very least, be sure to use a current version because a quick search turned up a number of known vulnerabilities. Remember that the files which you need to worry about may blow up imagemagick, even if they do not exploit one of the known vulnerabilities, so be sure to have REALLY good error trapping.