Can Access composer.json and package.json Anonymously

ℹ️ Support
1

So I’m tinkering around my server, just out of curiosity and decided to scan myself with dirb where I discovered I can access composer.json and package.json anonymously, and from an external IP, by just adding /composer or /package to the end of the URL. Is this normal, or a misconfiguration on my part somewhere? I’m using the archive method with my own Apache webserver setup on Debian 13. None of the information in there looks particularly sensitive; no hashes or passwords or anything, mostly just software and library version numbers and such, but I’m just curious.

2

Hello,

Same here.
all json files are accessible anonymously:
./nextcloud/apps/app_api/package.json
./nextcloud/apps/twofactor_nextcloud_notification/package.json
./nextcloud/apps/privacy/package.json
./nextcloud/apps/related_resources/package.json
./nextcloud/apps/suspicious_login/vendor-bin/psalm/vendor/felixfbecker/language-server-protocol/package.json
./nextcloud/apps/password_policy/package.json
./nextcloud/apps/recommendations/package.json
./nextcloud/apps/text/package.json
./nextcloud/apps/notifications/package.json
./nextcloud/apps/files_downloadlimit/package.json
./nextcloud/apps/photos/package.json
./nextcloud/apps/viewer/package.json
./nextcloud/apps/spreed/package.json
./nextcloud/apps/support/package.json
./nextcloud/apps/twofactor_totp/package.json
./nextcloud/apps/bruteforcesettings/package.json
./nextcloud/apps/firstrunwizard/package.json
./nextcloud/apps/files_pdfviewer/package.json
./nextcloud/apps/logreader/package.json
./nextcloud/apps/activity/package.json
./nextcloud/package.json

also all text files (AUTHORS, COPYING, REUSE.toml)

these files do not contain sensitive data, but I think this should not be accessible anonymously.

any idea how to do some hardening on these files ?

Thanks,
Regards

1 Like
3

NB: I put the list of package.json files, but it’s the same with all composer.json

4

This difference in behavior I suspect occurs if you’re not using pretty URLs. While sensitive stuff is blocked by the default .htaccess, other stuff isn’t necessarily. However, when using pretty URLs (which I presume is more common), every request ultimately flows through the main front-end controller (index.php). That controller has stronger URL confinement.

1 Like
5

Thanks a lot !

I confirm enabling pretty URLs now return 404 when accessing the files.

1 Like
6

This fixed it; I just added the following line to my config.php as it was missing:

‘htaccess.RewriteBase’ => ‘/’,

Then updated the .htaccess file with:

sudo -u www-data php occ maintenance:update:htaccess

index.php is now stripped from URLs and access to misc. json files, like composer.json, is now restricted, but URLs I’ve sent out for shared folders and such before the update, that still include index.php, still work correctly, they just auto-resolve to an updated URL without index.php in it.