Whitelist or blacklist file extensions for uploads

Question

I'm making a newsletter editor which will allow file uploads (the sender of the newsletter can upload files to the server which will be linked to in the email).

The site is set up so that only .do URIs are actually executed/handled by servlets so it's not much of a security risk, but I've been told to blacklist .jsp, .php, .asp, .aspx, .exe, .com, and .bat. This does not strike me as a comprehensive blacklist, and I've the impression that blacklists are not a good policy.

On the other hand, a whitelist would be dozens long. What's the correct way to identify allowable/disallowable extensions? Or is it more proper to just allow anything and run it by a virus scanner, or some combination of these?

Answer 1

In my opinion, even though the whitelist maybe a bit of a chore to maintain, it's far more secure than using a blacklist.

It's much better to forget to add something to the whitelist, and have to go back and change it, than to forget to add a new file extension to the blacklist and get hacked.

In addition to the whitelist, I would still virus scan the uploaded files, as even seemingly harmless files (such as .pdf or .doc) can have malicious code (.pdf's support javascript, and .doc macros)

Answer 2

Or is it more proper to just allow anything and run it by a virus scanner.

Yes.

Both blacklists and whitelists are trivially circumvented and cause just administration pain and provide no security whatsoever.

Answer 3

I would recommend you:

• Use a whitelist approach (by the reasons described above, it's fairly more secure)
• Check the filetype (bypassable but still one more measure)
• Store uploaded files in internal folders not exposed to the public (using non enumerative IDs)
• Set-up a low grade permission to the folder that will contain the uploaded files
• Set-up less privileges as possible to the uploaded files
• Make sure if there aren't secure libraries to upload files already available.

Antivirus aren't worth it. Most of web shells signatures are really easy to bypass since any 'hacker' can add some random code and do different types of encodings on an web shell. Sure it will protect you from common shells such as C99 but nowadays there are thousands of these tools publicly available and fully undetectable. And regarding protecting your users from executable files or infected PDF's hosted on your websites, if someone it's capable of get a shell on your site and start up a malware campaign it won't use malware or virus already spotted by av signatures.

Answer 4

I would allow any file extension to be uploaded, but I would store the files in a folder that is not directly served by the web server. I would then create a HTTP handler that would be linked to from the email, which would stream the requested file. The file could be requested either by original file name, a system generated file name or by an ID. Either way, I would sanitise the parameter to guard against directory traversal attacks.

e.g. www.example.com/FileLink.ashx?FileName=Word.docx

This way you do not need to worry if in future you wish to serve additional file extensions as executable file types, as any file is served directly from a byte stream from the file system and is never passed through the web server handlers.

You can also use the handler to check that the current user has the correct permissions to load the file.

It would also be worth virus scanning each file, just in case the newsletter author uploads (either maliciously or accidentally) a file that would attack subscribers' computers rather than the server.

Also ensure that the Content-Disposition is set to attachment:

Content-Disposition: attachment; filename="filename.html"

This guards against XSS being achieved by upload of HTML containing script tags, or other Same Origin Policy bypasses using Flash or PDF files. The scenario here is one newsletter editor compromising the session of another newsletter editor. It is worth also setting X-Content-Options: nosniff, which can also protect against this. xap files (Silverlight) could also bypass the Same Origin Policy, so check that the filename cannot be ended in .xap to request your file

e.g. www.example.com/FileLink.ashx/x.xap?FileName=Word.docx

and you could blacklist the setting the content type for Silverlight as extra protection for this special case. Source here:

Note: .XAP files can be renamed to any other extension but they cannot be load cross-domain anymore. It seems Silverlight finds the file extension based on the provided URL and ignores it if it is not .XAP. This can still be exploited if a website allows users to use ";" or "/" after the actual file name to add a ".XAP" extension.

Note: When Silverlight requests a .XAP file cross-domain, the content type must be: application/x-silverlight-app.

I've also verified these scenarios myself and are are currently valid attack vectors.