Question

A Django app that I am working has an Event model. An Event may have associated photos, static html files and pdf files.

I would like to allow trusted users to upload these files, but I am wary about security, especially having read the following in the Django docs (link).

Note that whenever you deal with
uploaded files, you should pay close
attention to where you’re uploading
them and what type of files they are,
to avoid security holes. Validate all
uploaded files so that you’re sure the
files are what you think they are. For
example, if you blindly let somebody
upload files, without validation, to a
directory that’s within your Web
server’s document root, then somebody
could upload a CGI or PHP script and
execute that script by visiting its
URL on your site. Don’t allow that.

How can I validate the different types of files? I would be interested to hear anyone’s experience of dealing with this kind of thing, or links for further reading. I have a gut feeling that html files may be too risky, in which case I’ll restrict upload permissions to the administrator.

Answer 1

All the answers are focusing on validating files. This is pretty much impossible.

The Django devs aren’t asking you to validate whether files can be executed as cgi files. They are just telling you not to put them in a place where they will be executed.

You should put all Django stuff in a specially Django directory. That Django code directory should not contain static content. Don’t put user files in the Django source repository.

If you are using Apache2, check out the basic cgi tutorial: http://httpd.apache.org/docs/2.0/howto/cgi.html

Apache2 might be setup to run any files in the ScriptAlias folder. Don’t put user files in the /cgi-bin/ or /usr/local/apache2/cgi-bin/ folders.

Apache2 might be set to server cgi files, depending on the AddHandler cgi-script settings. Don’t let the users submit files with extensions like .cgi or .pl.

However, you do need to sanitize user submitted files so they are safe to run on other clients’ machines. Submitted HTML is unsafe to other users. It won’t hurt your server. Your server will just spit it back at whoever requests it. Get a HTML sanitizer.

Also, SVG may be unsafe. It’s had bugs in the past. SVG is an XML document with javascript in it, so it can be malicious.

PDF is … tricky. You could convert it to an image (if you really had to), or provide an image preview (and let users download at their own risk), but it would be a pain for people trying to use it.

Consider a white-list of files that are OK. A virus embedded in a gif, jpeg or png file will just look like a corrupt picture (or fail to display). If you want to be paranoid, convert them all to a standard format using PIL (hey, you could also check sizes). Sanitized HTML should be OK (stripping out script tags isn’t rocket science). If the sanitization is sucking cycles (or you’re just cautious), you could put it on a separate server, I guess.