@NogDogSep 22.2007 — #Don't upload files into a directory which is directly accessible from the web unless you are going to detect and reject any file which is not of an acceptable type. (For instance, you don't want a hacker to upload his/her own PHP script and then be able to execute it by calling it from his/her browser.)
@hastxSep 22.2007 — #If your directory is web accessible...consider the nature of the uploads.
For example: if the uploads are resumes, you want to ensure that indexing is turned off on the directory. This will prevent someone from entering a bogus URL and getting full display of the directory contents. But if your uploads are just fun images you want to share, it may not matter to you.
Also, make sure the directory holds only the uploads. Don't upload to the same directory as your scripts.
@NogDogSep 26.2007 — #If your web files go in some directory like '/home/username/public_html' or '/usr/home/username/www' (whatever your "web root directory" is) or any sub-directory of that, then if you were to put the files in something like '/home/username/uploads' or '/usr/home/username/uploads' they would not be accessible via HTTP requests on the web.
@hastxSep 27.2007 — #Secure is a relative term, but yes, It is a good security practice to only ALLOW certain file types. You want to avoid anticipating what types of files to DISALLOW.
You could also test for file size: you can guestimate the size of a PDF (single page, with or without graphics) same with a jpeg (limit the size of the jpeg ...). This can help avoid someone simply renaming a file to get it uploaded. or consuming all your bandwidth on large uploads.
you get the idea. There are various conditions you can test for in order to achieve the level of security you think is required. [LIST]
[*]maybe have people register prior to using the upload functionality...
[*]only accept uploads from a range of IP addresses (for example: if it is a corporate intranet.)
[*]word verification on your form to help prevent automated form submission.
[*]Only allow access to the page if the referrer is the same domain.
[/LIST] These are all tactics employed on web forms for security.
@bokehSep 27.2007 — #Only allow access to the page if the referrer is the same domain[/QUOTE]That's a user defined variable, how can that have anything to do with security?
@hastxSep 28.2007 — #That's a user defined variable, how can that have anything to do with security?[/QUOTE]
not so much with uploads, but with blog entries and mail forms. Spambots often make direct requests, bypassing your form. Your script should only allow submission from the form url under your domain, denying external requests.
@bokehSep 28.2007 — #Spambots often make direct requests, bypassing your form. Your script should only allow submission from the form url under your domain, denying external requests.[/QUOTE]All browsers make direct requests. The referer variable is a variable they, and most robots choose to send (i.e. it is optional and can contain whatever false information the browser or robot chooses). As a user defined variable it has nothing to do with security, and certainly doesn't prove what form the client used.
@hastxSep 28.2007 — #I agree that referrer info can be spoofed. But my experience is that by default the popular browsers are configured to send correct referer info and spammers are not, which means that potential attackers are slowed down, and in the process some are discouraged.
As to whether it contributes to security... I would only consider it a link in a chain. If a spammer believes you had foresight, often they will just leave.