views:

156

answers:

4

What are the major security issues to consider when accepting image uploads, beyond the normal stuff for all HTTP uploads?

I'm accepting image uploads, and then showing those images to other users.

How should I verify, for example, that the uploaded image is actually a valid image file? Are there any known vulnerabilities in viewers that are exploitable by malformed image files for which I should be concerned about accidentally passing along exploits? (Quickly googling seems to show that there once was in IE5/6.)

Should I strip all image metadata to help users prevent unintentional information disclosures? Or are there some things that are safe and necessary or useful to allow?

Are there any arcane features of common image formats that could be security vulnerabilities?

Are there any libraries that deal with these issues? (And/or with other issues like converting progressive JPEGs to normal JPEGs, downsampling to standardize sizes, optimizing PNGs, etc.)

+1  A: 

Your biggest risk is that an attacker tries to upload some type of executable code to your server. If the uploaded file is then browsable on the web, the attacker may be able to cause the code to run on your server. Your best protection is to first save the uploaded file to a non-publicly browsable location, try to load it as an image in your programming language and allow it if it can be successfully parsed as an image. A lot of the time people will want to resize the image anyway so really doing this is no extra work. Once the image is validated, you can move it into the publicly browsable area for your web server.

Also, make sure you have a limit on file upload size. Most platforms will have some kind of limit in place by default. You don't want a malicious user filling up your disk with an endless file upload.

Asaph
How does serving up a file over HTTP cause it to run on the server?
Mitch Wheat
It depends on your platform. In PHP for example, if I upload an image called myhackerscript.php and then surf to it on your website, guess what? myhackerscript.php runs on your server.
Asaph
True, definitely, and that's good advice for any uploads. What about risks to my users, though?
Doug McClean
Mitch: In IIS, if you select 'Execute Permissions' as 'Scripts and Executables', and put an exe in the folder (say notepad.exe), it'll actually launch it. Hence you never allow that, unless you know what you're doing :)
Noon Silk
If you've validated that the file is a valid PNG or JPEG, I wouldn't worry about any executable code in those files. As for meta data in the image, you can strip it out, or if you're resizing, meta data is probably lost in the process any way. If you're worried about filtering image content, maybe add a "flag this image" feature and have your users help you censor unwanted images.
Asaph
Sorry, I was assuming this bit "unless you know what you're doing" :)
Mitch Wheat
+1  A: 

The risk of propogation of bugs inside image formatters isn't "exactly" your problem, but you can help anyway, by following the general practice of mapping ".jpg" to your executable language, and processing each image manually (in this way you can do refer checks as well).

You need to be careful of:

  • People uploading code as images (.jpg with actual c# code inside)
  • any invalid extensions (you check for this)
  • People trying to do path-related attacks on you

The last one is what you'll need to be wary of, if you're dynamically reading in images (as you will be, if you follow my first bit of advice).

So ensure you only open code in the relevant folder, and, probably more importantly, lock down the user that does this work. I mean the webserver user. Make sure it only has permissions to read from the folder you are working in, and other such logical things.

Stripping metadata? Sure why not, it's quite polite of you, but I wouldn't be nuts about it.

Noon Silk
A: 

One of the vulnerabilities I know of is a "WMF backdoor". WMF is "Windows Metafile"--a graphical format rendered by Windows GDI library. Here's wikipedia article.

The attacker is capable to execute arbitrary code on user's machine. This can happen when user just views the file via the browser, including, but not limited to Internet Explorer. The issue is said to be fixed in 2006.

Pavel Shved
+1  A: 

Some things I learned recently from a web security video:

  • The nuclear option is to serve all uploaded content from a separate domain which only serves static content - all features are disabled and nothing important is stored there.
  • Considering processing images through imagemagick etc. to strip out funny business.
  • For an example of what you are up against, look up GIFAR, a technique that puts a GIF and Java JAR in the same file.
Justin Love
Your first option is not easily achievable for most people, as it assumes you have a completely separate server that is is no-way related back to the main one (passwords, etc), and also is a little useless, depending on the goal of an attacker.
Noon Silk
What qualifier would you have suggested instead of "nuclear option"?
Justin Love