Apache2 reverse proxy setup exposing directory listings and serving unintended files
-
Hi,
FusionAuth was installed via Debian packages for reference. Running version 1.38.1.
We have FusionAuth set up behind Apache2 acting as a reverse proxy. I used the sample configuration available here as a starting point. I disabled all directory listings in the main Apache configuration.
This configuration works with little issues.
Our FusionAuth instance is running out of /usr/local/fusionauth/fusionauth-app/ which contains 4 other sub directories, bin/, lib/, template/, web/, 3rd-party-licenses/.
When testing behavior for this setup, it came to my attention that you could access, for example, the start script that is in the bin directory when navigating to https://ourfusionauthserver.com/bin from the browser.
The same can be said for the other directories at that level.
I added explicit ProxyPass exclusions for each of these paths at the virtual host level and it does have the intended effect of limiting access to these files from browser.
However, I haven't yet found this particular issue raised in other documentation, and it's making me think I have something configured incorrectly either in FusionAuth or Apache2.
If anyone has insight on this configuration or have resolved this issue themselves, I would appreciate the help.
-
@ctrenner Can you access FusionAuth configuration files or the log files? Those are in sensitive directories and shouldn't be accessible.
Everything under /fusionauth-app/ (bin, lib, etc) is available if someone downloads FusionAuth: https://fusionauth.io/direct-download
The leakage from those directories being available is which version of FusionAuth you are running, which could be helpful information to an attacker, but could be ascertained in other ways (looking at the structure of requests or the available templates, for example).
However, if you wouldn't mind submitting the changes you made back to that contrib config file, I'd be happy to review and apply them.
-
@dan The configuration files and logs are inaccessible, assuming you're talking about the ones residing up a directory from /fusionauth-app/.
Thank you for stating the risks of the leakage. The only thing that raised flags here was the default fusionauth.properties file in the template directory had the default database user and password, but those should be, and were, changed when installing.
I will fork and submit a PR later tonight or this week.
Thanks again.
