Dnn.platform: Standard File/Folders security and permissions

[mikebigun]

Description of bug

Users are able to access assets files in a Standard folder without View and Read privileges.

Steps to reproduce

1. Go to Site Assets and create Standard type folder
2. Add any asset to folder (i.e. any txt file)
3. Go to folder Properties -> Permissions
4. Disallow view and read permission
5. Get the URL of a file from the Standard folder
6. Log out from DNN
7. Navigate to the file URL

Current result

The file opens without having the permission to view it.

Expected result

Expected that file should be secured by the permissions and users cannot view or read it without having the permission to do so.

Screenshots

Affected version

• [x] 10.0.0 nightly build
• [x] 9.4.1 nightly build
• [x] 9.4.0 release candidate
• [x] 9.3.2 latest supported release

[mikebigun]

Dear community,

After some investigation I didn't come to any deserving solution. Here I would like to start discussion in a hope to find out something good to resolve this issue.

As you know there are few Folder types we use: Standard, Secured and Database.
When a Standard folder is used, we upload files to that folder as it is while Secured folder makes the files renamed by adding *.resource extension to the end. So, Secured folder does following:

1. It generates dnndev.me/LinkClick.aspx?fileticket=.... url to check permissions and read *.resource files.
2. IIS does not allow to list *.resource files. No way to view them in browser using direct links like dnndev.me/Portals/0/Test2/test.txt.resource.

In case of Standard folders, we use direct links like dnndev.me/Portals/0/Test1/test.txt
That means we have two problems:

1. We do not use any handlers to check permissions
2. If extension is in IIS white list, so direct URL it is not getting blocked by IIS. It does not depend on any permissions.

Some points to discuss:

• We can fix problem 1 by pointing files via dnndev.me/LinkClick.aspx handler to check permissions, but still, if someone will try to use direct link, he will be able to view the file, just because it is allowed by IIS.
• We can also change the type of a folder, move Standard type to Secured and add *.resource extension to all files. It will require us to rename all files. Based on experience customer could have a thousands of files, so not a good idea.
• We can say we do not provide Permissions management feature for the Standard folder. If user want to secure file and manage permissions, so he must go to Secured folders. Or move particular files to Secured folder if he want to hide them.

What else can we do in order to fix it?
The simplest option is the last one. Otherwise, I'm afraid, we need to do something with the files to block them on IIS level.

@ohine @mitchelsellers @sleupold @valadas

[bdukes]

Option three has been the position of the team, historically. If you need security for files, you must use a different folder provider.

[mitchelsellers]

At this point in time, the standard folder provider has never been suggested as the pathway to share secure file assets. The permissions as applied to "Standard" folders are simply permissions set to control who can view through the DNN Interfaces those folders etc.

Changing this direct linking behavior would have a catastrophic impact on site performance as remember this would impact every image or other asset managed through the HTML Editors. Therefore I agree that @bdukes is correct in that if security is desired, you need to use the "Secure" folder type.

_Lastly: PLEASE remember any security concerns should be directed to [email protected] and not directly here. I'm leaving this here as this is a documented feature, but for future reference, we need to be sure to adhere to the policies to not draw undue attention._

[mikebigun]

Great, so, based on that, I think would be good to hide permissions tab for the Standard folders. Just to avoid customers configure it for the objects that are not designed to be secured.

[mitchelsellers]

@mikebigun I would disagree, the permissions still are used to control who can administer/manage the folders when it is a standard folder.

For example, you can deny browse on a folder to prevent "Content Editors" from being able to make changes to folders etc.

Any removal of these permissions would be extremely breaking to all user types and integrations, as well as would restrict functionality

[bdukes]

Could the View permissions for Standard folders be disabled in the UI somehow? The other permissions for Standard folders are still useful, but View has no effect, right?

[mitchelsellers]

@bdukes I would have to look, but I believe that the CkEditor and others use the "View" permission to control if you can work with items in the folder, I would have to double-check though

[sleupold]

I agree with the above, and there are modules like Evotiva user files, we are using to limit access to download files being listed on the site, although all others are accessible, knowning their URL.

Just an idea: we could add a mocked "Direct download" permission, which is always true for all standard folders and always false for all other folder types. with a small tooltip, it should provide the necessary warning to any site admin.

[sleupold]

@mitchelsellers '
AFAIK, CKEditor is not using view permission but any file listing module should, including Digital Asset Management on public pages

[mitchelsellers]

@sleupold that's it! I knew something used it

[mikebigun]

Team, thanks a lot. I noted that.

Conclusion: to secure files from outside world, it is recommended to use Secured folders.

In fact, permission management is required for Standard type, just because we need to control other roles and assign different levels of access to administrate content in that folders.

[valadas]

Hmm, can't find it now, but there was another issues almost like this one with about the same discussion not too long ago. Or maybe it was in Forums

[JaySMa]

https://github.com/dnnsoftware/Dnn.Platform/issues/2790

[valadas]

That's the one yes, thank you

[valadas]

If I understand correctly this is by design and I am closing this issue.