List of public endpoints and resource paths

🚧 Installation
1

All the documentation and examples I have seen, and even the official htaccess, all implement a blacklist of sensitive files and directories that should not be accessible.

For example, from the htaccess in one of the official php-fpm docker container prevents access to the /config/ and /lib/ directories, and to the /occ and /console.php files among others.

Instead of using a blacklist, I would rather whitelist nextcloud’s entrypoints and public resource paths. Is there an official list of the public entry points and resources? Is this a bad idea? And is it even possible?

I created the list below using NC20, but the question would also arise for previous versions. Also I’m not sure if my list is exhaustive or allowing too much.

To figure out the paths to whitelist I used the htaccess at the web root in the docker image nextcloud:20-fpm-alpine and checked manually the directory tree, I skimmed the doc and in particular the developers’ guide (and found no official, exhaustive list), and I analyzed the requests made on a live instance (but it was a fresh deploy with not much on it; I don’t have a productive instance yet).

So far, I got to the following list ("*" matches anything, “?” matches a single path element):

# Common static files
/index.html
/robots.txt

# Nextcloud entrypoints
/cron.php
/index.php /index.php/*
/public.php /public.php/*
/remote.php /remote.php/*

/ocm-provider/*
/ocs-provider/*
/ocs/v1.php /ocs/v1.php/*
/ocs/v2.php /ocs/v2.php/*

# Static resources
/core/(css|fonts|img|js|l10n)/*
/core/doc/*
/core/(templates|vendor)/*

# Static resources for apps
/(apps|custom_apps)/?/(css|fonts|img|js|l10n)/*
/(apps|custom_apps)/?/(templates|vendor)/*

# Seems only used by scan.nextcloud.com, I'm listing it here for
# completeness but intend to block it unless I'm scanning
/status.php

I haven’t checked in depth the background job system yet, but from what I have seen, /cron.php is usually called without arguments.

I am also not very confortable with whitelisting everything in the templates and vendor directories

/core/(templates|vendor)/*
/(apps|custom_apps)/?/(templates|vendor)/*

because I found some php file in there that I don’t think are supposed to be served to the client, but I also found a few html files that have been requested by the client directly via ajax (I suppose that the client itself then processes the templates to replace the placeholders). I also found some open document templates, which I have no idea how they are used.

Finally I’m not sure about /ocm-provider/ and /ocs-provider/, I’ve seen one of them being called (I think it was /ocs-provider/) and added the other because it looked very similar.

Any help to improve the list, or pointers to an official list, would be appreciated :slight_smile:

Hash of the nextcloud:20-fpm-alpine image I used

sha256:27e1a221a839255731c5fa394540e4e58f6fa6d58a1ddf307303e308e8a9c118

1 Like
2

I think there was already a request for that… your list looks promising. Only difficult point are apps that can have different end points.

However, it would be great to put such a list on the documentation (github.com/nextcloud/documentation)

3

Is that actually possible? Do you have an app or two you could point me to to have a look?

Since my initial post I haven’t worked on that part much, but I found extra directories named ajax which, from the name alone, I think might need to be added to the list. But I haven’t seen any request made to those so far (and not tried very hard either, just played around with the files app a bit and it didn’t seem to be causing any issue when not whitelisted):

/var/www/html # find . -name ajax | xargs ls
./apps/files/ajax:
download.php  list.php

./apps/files_external/ajax:
applicable.php  oauth2.php

./apps/user_ldap/ajax:
clearMappings.php             setConfiguration.php
deleteConfiguration.php       testConfiguration.php
getConfiguration.php          wizard.php
getNewServerConfigPrefix.php

./core/ajax:
update.php

I’d be happy to submit a PR if that’s how it works around these parts. I think I have seen some documentation on hardening the installation somewhere. However I think it would need some official backing as such a list would need to be maintained afterwards.

4

Also used by the mobile and desktop apps.

1 Like