Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

As a web designer (not a security expert) I wonder: If I allow users to upload content to my website (videos, images and text files), what are the real risks involved?

share|improve this question
    
See also additional questions (but not quite duplicate): security.stackexchange.com/questions/323/… and security.stackexchange.com/questions/235 –  AviD Nov 21 '10 at 13:42

3 Answers 3

up vote 12 down vote accepted

There's a couple of risks from allowing content to be uploaded onto your site, but how important they are to you will likely depend on exactly how the site you're designing will work.

First up is malware upload. If an attacker can upload malware onto your site and that malware is downloaded and executed by your users then that's likely to be a problem. Preventing this usually relies on a combination of restricting the types of file that can be uploaded (one point to note is that you shouldn't just rely on file extension here), and using malware scanning on uploaded content. Of course the scanning side of things will only stop known signatures, and can be bypassed fairly easily.

Second potential problem is if they can upload active content and have that executed by your application. So for example if your site uses php, then if they can upload a php script and then get it to run as part of your application then they are likely to be able to take control of the server, or at least access other information that exists in the app.

One approach I've seen to addressing this is to ensure that the uploaded files are not placed in the web root and ensuring that the web server will not execute files from that location.

A third risk, is users uploaded "illegal" material. This can be a tricky legal question to sort, but if you allow user generated content you're likely to have to deal with it sooner or later. The fix for this seems to be primarily procedural. Have a good relationship with your hosting company and ISP and ensure that you can respond to requests to have content removed quickly, if you're hosting in a jurisdiction that requires content to be taken down if a request comes in (eg, a DMCA request).

share|improve this answer
    
Also, potential of flooding your server, thus causing DoS. –  AviD Nov 21 '10 at 13:40
    
A fourth risk, severe yet easy to miss: Upload of client-side active content, such as JavaScript (including HTML/CSS with embedded JavaScript), Java applets, Flash objects, etc., all of which can be used to perform cookie-stealing attacks and work around same-origin policies. Your website might think the user uploaded a GIF image, when it's really a Java JAR. Always host user uploads on a separate domain, cf. googleusercontent.com, upload.wikimedia.org, etc. –  Søren Løvborg May 14 at 23:05

If your server is not well configured, it could lead to execution of malicious code in the context of your server and take control over your files. One example of that is well known PHP backdoor c99shell. There are few recommendations to make this feature more secure:

  1. Use some other domain (or subdomain) to store files uploaded by users
  2. Make sure, users cannot upload any type of file the server will execute (check the content type or use language specific tools to read the content of file and check the right mime type)
  3. Make sure uploaded files have not permissions to be executed.
  4. When allowing other users to download the file, it is sometimes useful to force it as attachment using the Content-Disposition HTTP header
share|improve this answer
    
+1 for adding best practices examples. Thanks. –  Edgar Nov 19 '10 at 22:01

FileInclude is one of the worst security holes in websites, just think what will happen if some one uplode C99 Shell (which is one of the worst php scripts I've ever seen) to your site and execute it.

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.