Improve AjaxFileUpload security

[MikhailTymchukDX]

AjaxFileUpload is exposed to several attacks:
 

• Uploading a file with an arbitrary extension
• A DoS attack on the server where this control is located
• It is possible to obtain info about files outside the temporary upload folder

 
Consider improving extender security.

[MikhailTymchukDX]

We use a whitelist of file extensions that AjaxFileUpload accepts by default:

• 7z
• aac
• avi
• bz2
• csv
• doc
• docx
• gif
• gz
• htm
• html
• jpeg
• jpg
• md
• mp3
• mp4
• ods
• odt
• ogg
• pdf
• png
• ppt
• pptx
• svg
• tar
• tgz
• txt
• xls
• xlsx
• xml
• zip

The file extension check is performed on a server, so some users can receive errors if the whitelist does not contain an extension specified in "AllowedFileTypes" extender property.

In that case, a user can add custom allowed extensions with a new optional Web.config setting "additionalUploadFileExtensions". It contains a comma-separated list:

<ajaxControlToolkit additionalUploadFileExtensions="obj,pdb" />

Why does the white list override the AllowedFileTypes extender property? Shouldn't it be the other way around? It would seem to me that if I explicitly allow it via the AllowedFileTypes property, then I want it included and shouldn't have to also go to web.config and add it there as well, which is something I can't do as easily on the fly like I can with the property. E.g. in my application, we allow the end-user to specify some of the file formats they want to allow uploaded. If AllowedFileTypes is no longer used, why is it still there?

Also, the example for the entry into the web.config file has no context? Where in web.config does go?

[AlekseyMartynov]

Hello @Westernstandard

If AllowedFileTypes is no longer used, why is it still there?

AllowedFileTypes is still used to narrow down the global whitelist of allowed extensions. For example, to configure a certain instance of AjaxFileUpload to accept images only.

Also, the example for the entry into the web.config file has no context? Where in web.config does go?

Good point. An exact location can be seen in web.config of the AjaxControlToolkit.SampleSite project.

We have introduced the whitelist to prevent any attacks aimed at uploading malicious files. It's configured globally on the app level so that it cannot be affected by tampering requests or by changing the content of ASPX pages.

We can add an option to disable it for apps which run in trusted environments. Would it be helpful in your case?

It would. I have a lot of xml based file types that we need to support.

I applaud efforts to increase security. However, and forgive my ignorance, it seems like the list of AllowedFileTypes would ultimately be a shorter list than the white list and exactly what the developer intends. If the developer intends to allow exe files, then I would hope it's in a trusted environment.

Perhaps the whitelist could be overridden if allowed at the application level in web.config?

[MikhailTymchukDX]

@Westernstandard It can be extended, not overridden.

[AlekseyMartynov]

it seems like the list of AllowedFileTypes would ultimately be a shorter list than the white list and exactly what the developer intends

Per our design, AllowedFileTypes is indeed shorter but it cannot contain extensions not permitted by the global whitelist. The current behavior is intentional. I agree with you that it might be less convenient but it is more secure.

I have a lot of xml based file types that we need to support.

Please help us better understand the case.

1. If that list is known in advance and maintained by a developer, then additionalUploadFileExtensions of web.config is the best way to go.

2. If it needs to be configured in runtime by end-users, without any restrictions, then we need to add an option to disable the whitelist.