Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

A recent project requires one of our websites to accept file uploads from (logged in) users (primarily images and possibly some video).

What are some (generic) things we need to take into account, check for, ensure, or calculate, as we bring this project into fruition?

share|improve this question

8 Answers 8

up vote 4 down vote accepted

You need to look out for:

  • Maximum file size. This can be done by the web developers in many cases.
  • Permissions. Do you want each user to have their own (virtual or real) folder that nobody else can see?
  • Do you want users to be able to delete files they have uploaded, or even see them? They should probably be able to verify what files they uploaded at the very least.
  • Do you want to enable users to download files as well as upload? This may be tricky to implement depending on your setup.
  • Make sure that the uploads folder does not allow them to go up the directory tree.
  • Will you limit files by extension or other criteria? You want to make sure you don't set up a "warez server" inadvertently. I know this is for logged in users, but any security can be broken in some way.

This is all I can think of at the moment to look out for.

share|improve this answer

Just some things I've come across while writing a file upload thingy:

Make sure you clean or filter filenames of uploaded files. (get rid of .., \ and / and probably a bunch of other things depending on your OS)

Don't assume that filenames only have one "extension". "report.doc.pdf" or "Makefile"

If the uploads are expected to be large you may need to worry about people with slow connections (remember a lot of people are on DSL with often relatively slow uplink speeds). They may regularly experience disconnects or timeouts. Some older web browsers would timeout when uploading large files. You need to find a way to deal with this, or to check that uploads completed successfully.

Upload the files to somewhere "safe". On a UNIX system this would ideally mean a drive with "noexec" set, and with a disk quota on the account that is uploading so it can't fill the drive completely.

If you're holding the files on a system with automatic document indexing (most Desktop OS's), exclude the folder they're stored in from that indexing. For example there have been vulnerabilities in the Windows one recently (indexing a bad PDF), and there will likely be more in the future.

share|improve this answer

My quick list of what you should think about:

1- Application, protocols (ftp, secure ftp, http, webdav, etc.) and configuration

How will the files be uploaded? Is there a front-end app that will be managing it? What ftp server will you be using? There is no right answer here, you simply want to figure it out in advance to make certain the remaining items are done properly.

2- authentication and user management

You need to decide how credentials and authentication will work. Don't allow anonymous uploads! Will there be generic users, or named users? Who will manage the users? Will they be controlled through the application, through the OS, or some other way? Will they be allowed to delete? Only their files, or anyone elses?

3- file locations and disk space

You need a place to put the files. Will this be a permanent location, or will there be a process to "sweep" them into another location? Will each user have a separate place, or will there be only one place? Will there be a max size per file? Do you want to restrict the file types allowed?

share|improve this answer
  • Max file size, both on the client with a MAX_FILE_SIZE (if you're uploading via HTTP) and during the server processing step.

  • Consider keeping the uploaded data on a separate partition (typically webservers dump to /var/tmp) to prevent someone from filling up something important. You might consider a paranoia step of mounting this partition with -o noexec.

  • That the image/video uploaded is actually valid data. Someone might rename a binary to funtimes.jpg, or append a RAR file to the end of an image. Steganographic concerns might not be at the top of the to-watch list, but many services let users launder data through them.

share|improve this answer

Implement some kind of anti-virus / malware detection on the server. Even though you are accepting supposedly "non-executable" file types, there is still the possibility of executable code in those files that takes advantage of buffer-overrun vulnerabilities.

share|improve this answer

Treat every uploaded file as untrusted until you prove otherwise. Virus scan them, the works.

share|improve this answer

Here are a few issues that I recall from doing this in the past:

  • Memory Usage; make sure your process is writing the upload out to disk instead of memory. For ASP.NET, this would require writing your own HTTP handler.
  • Content Limit; your web server and any upstream proxy servers or content analyzers will need to support the increased content length.
  • Timeouts; scripts, firewall ports and proxies should be configured for long timeout periods as the uploads may take a long time to complete.
share|improve this answer

One big thing to watch out for is the max file size you want to allow. Make sure your server is configured to allow the upload of files big enough for your requirements.

Also, I highly recommend the target folder for the upload to be outside of your application's root folder structure.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.