How to hide the data directory from external access

[jurgenhaas]

Thanks a lot for this great plugin and for the ongoing maintenance.

Since I installed the latest update,when I'm going to the RainLoop admin panel, I'm getting a warning, that the data directory should be hidden from external access:

Is there some advise on how to do that for the integrated instance or is it even necessary in the Nextcloud context?

[enboig]

Also interested in this

[pierre-alain-b]

Hello all,
Yes, as a matter of fact I spotted this as well yesterday after the update. But I had no time to investigate thoroughly but a quick test on my instance showed that the data/ folder was apparently not leaked outside of Nextcloud. If confirmed, this would be a very minor issue for mono-user instance, presumably a bigger one for multi-user instances. I shall report as soon as possible, I hope later today. If some of you can test and help me evaluate what is effectively accessible in the nextcloud context, it would immensely help!

[jurgenhaas]

I was under the same impression, that the data directory is not leaked but I wasn't quite sure. At least the warning produced by the RainLoop library must have some means to determine the fact and if they thought it was true, there might be some tricky way, I just couldn't find out.

[zinsserzh]

The warning disappeared after I blocked this url in the Chrome developer tools.

/apps/rainloop/app/data/VERSION*

I don't have time to check the code, but I assume that a 403 is expected while nextcloud generates a 302 redirect.

[pierre-alain-b]

The code responsible for this in Rainloop is here: line 32
https://github.com/RainLoop/rainloop-webmail/blob/90a3d2b62a626b05b914cdf597fd0b9466803ddc/dev/Stores/Admin/App.js

if (settingsGet('Auth')) {
    $.get('./data/VERSION?' + window.Math.random()).then(() => this.dataFolderAccess(true));
}

And as said previously, Nextcloud does reply to this by redirecting the request to the Files application. So Rainloop wrongly considers the data folder is open.

[pierre-alain-b]

And
$.ajax({url: './data/VERSION?' + window.Math.random(),type: 'get'}).done(function(data, statusText, xhr){var status = xhr.status;console.log(status);});
logs the status code 200... because it seems it follows the redirect and gives the status code of the redirected query.

[zinsserzh]

Yeah, ajax always follow redirects silently. It's part of the XMLHttpRequest and can't be overridden. I reasonable solution would be to check if the final response URL is the same as the original one (meaning redirects happened). I'm not sure if it is safe to treat redirect as a passed test tho.

[pierre-alain-b]

Or we may test the content of the retrieved file and see if this is what is expected (the current content of the VERSION file is "1.12.0"). What do you think?

[zinsserzh]

If we are going to verify the content, I think at least the "expected" content should not be a hard-coded string. Either retrieve its content via a legal method or get the version number from somewhere. If so, I think it's fine.

[feutl]

Is there a fix now?
Are there any implications?
Do I need a .htaccess file in the "rainloop-data" directory or not? based on my ticket #69 this questions are still unanswered.

[pierre-alain-b]

• No, we discussed the fix but I have not implemented it yet.
• As far as I (and others) have analyzed, there is no implication and in fact it is a false positive
• No need of a special .htaccess file

[feutl]

Great, this is what I was unable to "figure out" based on the discussion.

Thanks

[truhi]

I've just discovered that web-folders after /data/_data_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx are fully readable without any authentication.
For example: https://xyz.com/rainloop/data/_data_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/_default_/storage
Which I believe reproduces the issue.