One thing this doesn't touch on is using a one-way hashing algorithm on your file uploads. This allows your application to do another layer of verification. This also obscures filenames so that they cannot be easily indexed (e.g. Google search engine...)
By one-way I mean md5 or sha1. They're extremely useful for one-way validation in cryptography/security. Applications of these are storing passwords (e.g. normally you should salt and hash passwords before storing them in a database) SHA is usually stronger (~160 bits) than md5 (~128 bits). Although, weaknesses have recently been found (~2005?) in these algorithms; it's easier than predicted to find hash collisions. NIST is sponsoring the creation of successor functions to these current one-way hashing algorithms.
I want to make sure that I understand your first comment correctly. Were you stating that upon file upload, the filename should be encrypted so that the malicious user would not know the name of the file stored on the server and thus not be able to execute the file directly?
Pretty much... more along the lines of that users should only interact with specified UI. Hashing filenames abstracts the media (files) from the user, leaving the application to deal with managing said media.
E.g. If Facebook were to store profile pictures as the users' name, people would be able to access images based on altering a URL. The HTTP protocol (most likely) wont know if the current user entering the URL has "permissions" or "is a friend of" the picture it is requesting from the server...
However, if it's important to disallow random access to the uploaded file, you really need to put access controls on it, and store it outside of the HTTP root. Obscuring the filename isn't enough.
