Convince System Administrator that File Uploads can be Okay?

Question

To keep this as short as possible: It was recently brought to the attention of our system administrator (as this type of thing should be) that one of the requirements for our latest web-based project would be allowing customers to perform file uploads. In particular these will be primarily images and possibly video [, but as I'm sure you know, you can't guarantee what the exact content of the upload is until it's on the server].

The system admin was quite a bit put off, and came just short of a blatant "No!".

I am familiar with many of the best practices concerning input from users, handling uploads, etc, so I am very confident about the behind-the-scenes/code aspect of this project. My question is, are there any specific resources or points of conversatation to bring up to ease the mind of my system administrator? What should I focus on explaining to him about this sort of thing, how it's handled, etc?

Some concerns are potential storage space (which I know needs to be calculated based on estimated "popularity" times estimated file-size) and security issues with hosting uploaded content.

Answer 1

At the end of the day, both you, and the admin, are there to support the business' needs. The challenge is finding the right balance of functional (uploading files) and non-functional (security, disk cost, performance) approaches.

• Whitelist allowed filetypes, so that the site doesn't become someone's personal MP3 archive site.
• Set reasonable file upload sizes, and design in a way for admins to assist with workarounds for large but necessary sizes.
• Implement rate limiting. Does Jane really need to upload 5 files simultaneously, or 300 files in one day? Generally these should be set at a rate that's invisible to the normal user, but quite apparent to an attacker.
• understand the way your application will consume resources - memory and disk. If you're egoing to chunk, what are you going to do to clean up dropped sessions? How much does memory does a 10 MB file consume on the server while it's being uploaded?
• Understand the lifecycle of the data. When will it no longer be needed? what triggers its deletion?
• What will your app do when antivirus quarantines an uploaded file?

Answer 2

Everyone who recommends checking file extensions as a way to make sure you're safe is insane. It's easy enough to rename an exe or an mp3 to a gif. Ditto for the upload MIME type.

The only way to be sure of the upload type is to parse it; look for the file signatures within the file, load it into an image processor and see if it chokes, etc. etc.

What else you need to do depends on your OS and web server, but generally uploads should not go onto a separate disk, so you don't kill your OS when someone uploads lots and lots of files and takes all the space up. Wherever they are uploaded should not contain execute permissions, so no-one can run a file from there via the browser (just in case it's a script in whatever web language you're using), even better don't allow direct references to it at all, serve the files via a utility page with something like a GUID as the parameter (e.g. displayImage?id=0000-000000-0000-0000)

And of course virus scan, limit the maximum upload size (although beware of that, IIS6 for example cannot check the stream length mid way through, and so will store the upload in memory till it's finished and then passes it onto your asp.net application)

Answer 3

Read this site: http://www.owasp.org/index.php/OWASP_Top_Ten

You'll notice that "upload magically corrupted Apache" isn't a well-known security vulnerability.

Apache upload handling can be botched -- and botched badly -- but you really have to work at it by ignoring the OWASP vulnerabilities list.

Further, your framework -- which you didn't mention -- has specific guidelines for handling uploads in a secure way. If it doesn't have any provision for uploading, then run -- don't walk -- to a better framework.

---

"[, but as I'm sure you know, you can't guarantee what the exact content of the upload is until it's on the server]."

Far from true. And irrelevant even if it is true for your particular framework.

Files pass through buffers. The Python frameworks make the upload available in cache (if it's huge) or in memory (if it's small.) It isn't "really" on the filesystem even if it's in a file-backed cache. It doesn't have it's final name or permissions -- it's just bytes.

Bytes don't magically corrupt Apache. Exeutable files with dumb ownership (and/or a setuid bit in their permissions) corrupts Apache.

The trick with uploads is to (a) leverage your framework's caching, (b) validate the data before saving it anywhere, (c) save it someplace non-exexcutable -- someplace Apache cannot look for executables, and (d) never chmod or chown anything under any circumstances. A non-executable upload can cause problems if it's named .htaccess and your wrote it into the directory Apache fetches this from -- an action that's easily prevented by setting the permissions on this directory and never naming an uploaded file .htaccess.

There are remarkably few vulnerabilities. They're well documented. And your framework already handles this.

Answer 4

If this is a vital part of the business requirements, I can't see how he could refuse as long as the security protocols are followed (i.e. filter file extension/type, MIME type, size of file, etc.)

Assuming he's part of a corporate ladder (and not the only sysadmin in the company) try going to his supervisor and explain your situation.

Answer 5

Bear in mind that you can verify the type of uploaded files (using MIME type detection; there are various ways of doing this in PHP, or using an external utility such as file), and you can scan them for viruses, again, using an external utility.

Presumably, once you've processed and verified an uploaded file, you'll move it into its final location, and you'll reject files which don't pass these phases; if that's so, you may be able to reason with your administrator that you'll only be saving "safe" files.

You might start by asking him what his major pain points about the issue are; is he concerned with safety/security, with being responsible for publishing content provided by other users (and any end-user security implications that raises), or is he concerned about infrastructural issues - storage, network, etc.

Note: "Safe" above refers to safety within the checks performed. Obviously, you can't guarantee the absolute safety of anything the user provides.

Answer 6

File uploading can be complicated to manage, security wise and in general.

In order to have a safe enough application you will need to...

1. Limit file size. You don't want people using too much bandwidth or use your system to store all their data.
2. Limit uploaded types (do not allow .exe or bash scripts...). You can do it just by checking the file extension. Actual file type checking can also be performed, but in most cases it would be overkill. Depending on the language/system you're using, there are various ways to do it.
3. Be carefull with some formats that present security holes.

Then it also depends on the trust you put into your end users. If it's an intranet where everything is tracked, you don't need as much security as a public website! If the users are known you will not have to check everything as much.

Answer 7

Another good sanity check--don't upload files to disk, but rather store them in a database. This kills off the classic "upload evil file, then execute evil file in server context" because the files don't exist on the server.

Now, you can always get crafty about serving the files for download if you have performance issues with db-backed files.

Answer 8

Having been that admin that said, "uh, no." to developers asking to upload files to the server, I can tell you the things I look for in an application that looks to do that. The prime constraint is that unless we're talking about a dedicated web-server, our web-servers were not sized with mass file-storage in mind.

• What is the data retention cycle? If that data will be on the web server forever and ever, I'm much more likely to force that application onto its own dedicated server. If that data is only on the server for a few seconds while the software parses it and then deletes it, I'm much more likely to let it happen. I get encouraged when there is a scavenging process that cleans out dead/old files. It shows they care.
• What size files are we talking about? If it's weensy office-doc files, that's one thing. But whacking huge GIS shape files are another thing entirely.
• What is the intended audience? If anonymous internet users can upload files, it seriously increases how paranoid I have to be about that data.

Answer 9

One of the startups I worked for a few years ago was a video and image uploading site on Linux (so all my example are from that). There are a number of things that can go wrong with allowing uploads.

All upload systems should transcode the original format to your standard format. The benefit of this is twofold. First you now have a standard format which makes displaying the images and videos much easier on your html. The next if you're somewhat assured that you've changed the file enough that you're not hosting infected files. If you're planning to serve raw uploaded files from any user with an email address, you can have a fair amount of trouble.

As other people have mentioned you need a bit more than just checking the extension. This is a bit harder problem to solve. We took a couple of stabs at it that I was never happy with, but it's worth doing for a couple of reasons. The big one is that you will likely have multiple paths for transcoding video. Video comes in many different containers along with a few million combinations of audio and video tracks. The more you know about the file the better choice you'll make on how to process it or ultimate reject it.

Assuming you're transcoding the files, you're vulnerable to exploits in your processing libraries like ffmpeg or libgd. We'd write the original file to disk on the NFS share and then spawn the processing in a jail/chroot environment. This allowed us to transcode to a new format or fail in a single directory without infecting the server or any other files. Also your transcoding system needs to be very up to date so you need to be checking with your distribution each night to make sure the underlying libraries like libpng, libtiff, libmad, libdv, etc don't have any current security bugs.

Going back to the original question, make sure you're addressing the issues pointed out by everyone and you should have no issues getting your sysadmin on board and have a far better application in the end too. Unfortunately your sysadmin's job is say "No" to things that look like they will be an operational nightmare to support.