Security considerations when uploading files

Damian Jakusz-Gostomski — Sun, 14 Feb 2010 13:21:55 +0000

The ability to upload, share and download files is key successfully collaboration on a project. As well as being able to just have the uploaded files stored online, I want the users to be able to interact with them. This means if it’s an image file, it should be displayed within the application, instead of having to download it to view it. If it is some textual document (or any ASCII encoded document) it should be possible to view it. If it’s a zip archive, it should be possible to view its contents etc.

Of course with added flexibility come complications, mainly in terms of security. In order to embed an image within a HTML page, that image needs to be within the web root, which means it can be accessed via URL from a browser. This in itself isn’t a security issue per se but it is a privacy issue, as a users uploaded images would be visible and accessible to anyone.

Things could get worse a whole lot quicker if we stored all uploaded files within the web root. If someone uploaded a PHP file (or any other executable file) then they could place malicious code in there, and then browse to it via URL.

So we need to either be very careful about what we allow users to upload, or not store it in the web root. The following is how I aim to tackle the problem.

When a user upload a file (of any type) it is stored out of the web root
When a user tries to view a file (either on the mail files page or viewing a single file) if it’s an image, a copy of the image with an encrypted file name is copied to a tmp directory within the web root
Any page within the application references this temporary copy, which gets deleted every X minutes by a cron job
To make things a little more secure, as well as encrypting the file names, it will not be possible to view the contents of the tmp directory via the browser

So the only way a user could view an image not belonging to them, is if they happen to “guess” the correct 32 character encrypted name of the file in the space of an X minute window before the contents of the temporary directory get wiped.

Oh, and this only applied to images, everything else can stay in the upload folder outside of the web root and still be accessed ok.

Now I know this method isn’t totally full proof so I will try to devise some additional authentication, maybe using some more .htaccess trickery… If anyone has any suggestions, then please add them in the comments.

An initial start on the files section

Damian Jakusz-Gostomski — Sat, 06 Feb 2010 17:28:20 +0000

Today, I did some work on the files section of Project Trackr. There is nothing fancy at the moment, just the ability to upload a file, view a list of all files, view details of a single file (just a dump of the relevant database row) and the ability to download a file. At the minute, all this functionality is still in it’s infancy, but one thing I’ve added is the ability to download all your files in a single zip archive. This works, but it’s not really intuitive in it’s current form.
It suffers from the following problems
It includes all your files, this means it can be a pretty big zip file to download
There is no way to select which files to include and which to exclude
There is no hierarchy within the zip – Everything is in the top level

So we need to be able to select which files we want to include, so the obvious suggestion would be be list all the files and have a set of checkboxes to select the files you want. This still seems like a lot of work, and it get’s worse when you need to paginate the list of files, as you would either need a form submit to move to the next page or use AJAX to track the files being added in real time.

What are your thoughts? Is this sort of thing useful? Should it just include all files or let you select etc? Let me know your thoughts in the comments

Project Trackr Development Log » Files

Security considerations when uploading files

An initial start on the files section