Convince System Administrator that File Uploads can be Okay?

Solution 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?

Solution 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)

Solution 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.

Solution 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.