I’ve just set up a Nextcloud installation on my home server, and I’ve been really impressed with the quality and security-conciousness of the support - both in the official docs in these forums.
There’s one thing I’m a little curious about - no-one seems to mind that the config.php file (with the database login details) is inside the webroot. This is debated heavily among WordPress users, another php+database+files app (e.g. https://wordpress.stackexchange.com/questions/58391/is-moving-wp-config-outside-the-web-root-really-beneficial#answer-58820), most of the risks stemming from the idea that a small misconfiguration, or backup/restore issues can result in those details becoming public.
Any reason why the same arguments don’t apply to Nextcloud?
No. There were some efforts to move the data folder outside the webroot.
Problem is, somewhere in the code we must put the path to the config file. So a config file for the config file. Our concern was if someone has access to the config file. So in this case, this person wouldn’t have access to the config file but to the config file for the config file, isn’t that somehow the same (you can change the config file, invalidate parameters, return values, …)?
I think the primary risk is that by default, a web server serves files, it’s the special configuration (ie. to call the PHP handler, or choosing to respect .htaccess) that makes it do something other than serving that unprocessed .php file and handing over your database credentials to an attacker. A screw-up in the configuration that resets it default can expose that file.
The risk is higher with multiple virtual hosts, because a misconfiguration in any one of them could results in that file being exposed. Putting the config file outside the webroot makes that much more unlikely to happen accidentally. (A maliciously configured vhost is another matter).
PHP can access files that the webserver wouldn’t serve (and that access restricted with the open_basedir directive if desired).
I wonder what they would do with the database login though. In my case, and many others I would think, I run MariaDB in a closed Docker network with no exposed ports to the database. To connect to the database, they would have to gain access to the host server, in which case the database would not be my chief concern, or the attacker’s. They would be after my data folder.
If an attacker gets access to the DB your entire installation is compromised. I imagine an attacker would change passwords or copy/craft authentication tokens to log in as any user they like, and download everything.
I acknowledge that damage from released database credentials is mitigated by how well protected the database login port is: With Nextcloud and the database on the same machine that’s easy to protect with a firewall that blocks everything trying to access the database port from outside that machine, doable but trickier if they’re not the same server. However, a firewall protecting the database port like that doesn’t help if the attacker has shell access (including unprivileged) to the server.
I also get that the risk of webserver misconfiguration is low, especially with modern setups such as containers or even separate virtual machines.
If the community has concluded the risk is low enough for it to be not worth bothering with then I’m OK with that - I was just curious why the two communities of users (WordPress and Nextcloud) had come to different conclusions about this common situation.
I know years ago the software Jommla stores the MySQL-DB-credentials in config.php without security options.
config/config.php from Nextcloud is secured with Htaccess.
config/.htaccess:
# Section for Apache 2.4 to 2.6
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule mod_access_compat.c>
Order Allow,Deny
Deny from all
Satisfy All
</IfModule>
# Section for Apache 2.2
<IfModule !mod_authz_core.c>
<IfModule !mod_access_compat.c>
<IfModule mod_authz_host.c>
Order Allow,Deny
Deny from all
</IfModule>
Satisfy All
</IfModule>
</IfModule>
# Section for Apache 2.2 to 2.6
<IfModule mod_autoindex.c>
IndexIgnore *
</IfModule>
That was my point. By the time the system is compromised enough for the attacker to actually use database credentials, it’s game over anyway because they can just ignore the database and download your data folder instead.
So, securing the server is a much greater concern than an unusable, random password to a database that can’t even be accessed.
The vast majority of Nextcloud users do have the database on the same server.
Often these attacks combine various issues, with this they can get the db credentials, somewhere else there might be other issues (configuration issue, unpatched security fix, other software on this host, …).
.htaccess files are not enabled by default in Debian/Ubuntu, and the installer doesn’t check that they are, which is exactly the kind of misconfiguration that can get you into trouble ;-p
Without activated Htaccess Nextcloud would not work because of wrong rewrites.
Test it with renaming /path/to/nextcloud/.htaccess to .htaccess-not-used
It works great! The Admin Overview page does tell you about the WebDav discovery URLs not working, but doesn’t put it in yellow or red to indicate a serious issue.
To go back to original issue - the risk (exposing the DB login) is from server misconfiguration (including from a different vhost), so pointing out the correct config doesn’t help mitigate that.