File extension whitelists for end users #3633
Conversation
DNN Platform/Library/Common/Utilities/FileExtensionWhitelist.cs
Outdated
Show resolved
Hide resolved
DNN Platform/Library/Common/Utilities/FileExtensionWhitelist.cs
Outdated
Show resolved
Hide resolved
DNN Platform/Library/Common/Utilities/FileExtensionWhitelist.cs
Outdated
Show resolved
Hide resolved
DNN Platform/Library/Common/Utilities/FileExtensionWhitelist.cs
Outdated
Show resolved
Hide resolved
| /// <summary> | ||
| /// Gets whether the user is in the portal's administrators role | ||
| /// </summary> | ||
| private bool? isAdmin; |
There was a problem hiding this comment.
Given that the calculated value is never stored/used, no need for this to be a private backer
There was a problem hiding this comment.
Not sure I am on the same page, but I am pretty confident that once we have this value then extension developers will begin using this value more and more instead of coding their own IsAdmin logic. And that might require accessing the value multiple times in your code.
On the other hand one could argue that maybe an extension developer might change the user's roles and then recalculation would be necessary.
On the fence about it. Given that the calculation is not trivial I persisted the value.
| /// | ||
| /// The only time we should call this is if the host allowed extensions list has changed | ||
| /// </summary> | ||
| public void CheckAllPortalFileExtensionWhitelists() |
There was a problem hiding this comment.
If this is internal, can we mark this internal to prevent external callers?
There was a problem hiding this comment.
Additionally I think we might want a bit stronger name on this, as this isn't a check, it actually updates/changes data if necessary
DNN Platform/Website/Install/DotNetNuke.install.config.resources
Outdated
Show resolved
Hide resolved
Co-Authored-By: Brian Dukes <bdukes@engagesoftware.com>
Co-Authored-By: Brian Dukes <bdukes@engagesoftware.com>
Co-Authored-By: Brian Dukes <bdukes@engagesoftware.com>
Co-Authored-By: Brian Dukes <bdukes@engagesoftware.com>
|
Looks like tests are failing. I only glanced at the error, but you may need to add a mock value for this new setting or something like that. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
Is this fix for CVE-2020-5186. Why there is no release description for security fix? |
|
@neal1991 Security issues ARE NOT DISCUSSED here per the terms of our security policy. If this is applicable to a security notice it will be published as part of the Security Bulletins as part of the release process. We DO NOT publish security bulletins for RC releases. |
Currently DNN uses one single file extension whitelist that governs what administrators and end users can upload (AE: Security > More > More Security Settings). This list includes files that may be needed by administrators to upload content to manage the site but that end users have no business uploading. This PR introduces a new whitelist mechanism that allows site maintainers (i.e. admins) to control what end users of a site can upload (within the limits of their own whitelist). Specifically this solution does the following:
It introduces a second whitelist setting (AE: Security > More > More Security Settings) for the host called "Default End User Extension Whitelist". If an administrator does not define an end user whitelist, this list will be used.
It allows the administrator to define a whitelist (AE: Site Settings > Site Behavior > More) called "Permitted File Extension List". The UI includes a dropdown which allows the admin to specify "default" (i.e. what is defined in 1 above), "custom", or "images only".
Upon update of any of the above settings and the global whitelist, there is a cascading check to ensure no end user whitelist allows uploading of a file not allowed by the global whitelist.